Discussion :

[coyotte507]

Bonjour,

Non je n'utilise pas boost.


Je voulais savoir, lorsqu'on d�truit un thread avec le m�chant KillThread() d'une biblioth�que C, est-ce que les destructeurs ont le temps d'�tre appel�? Sinon je risque de me retrouver avec un probl�me avec les strings...

De m�me, est-ce que si on appelle une fonction dans le thread, elle se termine m�me si on tue le thread? (Par exemple si je fais une fonction dangereuse du genre un string::swap(), y'a-t-il des risques?)

Merci de votre aide

[JolyLoic]

KillThread n'est pas une fonction C standard, je ne sais pas de quelle biblioth�que elle vient. La r�ponse peut d�pendre.

Si elle est vraiment "m�chante", la r�ponse est non : Tout s'arr�te de suite, rien d'autre ne s'ex�cute. La m�moire n'est pas lib�r�e, les mutex restent pris,... En g�n�ral, si ton but n'est pas de quitter le programme juste apr�s, tant pis pour toi.

Apr�s, il existe des fonction assassine qui au lieu d'y aller au bazooka utilise un poison lent, qui permet au thread en question de se rendre compte qu'il va mourir et de pr�parer sa succession (voire de prendre un antidote). Une possibilit� pour �a est de g�n�rer une exception ou �quivalent dans le thread en cours, ce signal remontant la pile d'appel et laissant donc un nettoyage se faire. La difficult� principale de cette m�thode est de d�terminer quand l'�mission de cette exception peut se faire sans nuire au thread. Un probl�me connexe est qu'il est possible que le thread mettre tr�s longtemps � mourir, voire refuse de le faire.

[Spout]

Je ne connais pas KillThread() non plus, mais TerminateThread() correspond exactement � la description de JolyLoic.

Cf les remarques de TerminateThread() si cette fonction t'int�resse.

[coyotte507]

Merci pour vos r�ponses.

En fait c'est la fonction SDL_KillThread de SDL, en t�l�chargeant le source j'ai vu:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
/* WARNING: This function is really a last resort.
 * Threads should be signaled and then exit by themselves.
 * TerminateThread() doesn't perform stack and DLL cleanup.
 */
void SDL_SYS_KillThread(SDL_Thread *thread)
{
	TerminateThread(thread->handle, FALSE);
}

Voil�...
En fait c'est TerminateThread, dans le lien donn� par spoutspout il est dit:

TerminateThread is used to cause a thread to exit. When this occurs, the target thread has no chance to execute any user-mode code. DLLs attached to the thread are not notified that the thread is terminating. The system frees the thread's initial stack.

Donc la pile est nettoy�e, c'est d�j� �a, mais je pense que je vais �viter au maximum de l'utiliser (juste un pointeur sur classe), quitte � faire un thread dans un autre pour g�rer les mutex etc. proprement.

Je n'ai pas tr�s bien compris ce qui arrive avec les DLLs, est-ce que �a pose probl�me si j'utilise une fonction d'une DLL? Par exemple si j'utilise la fonction SDLNet_TCP_Send, qui est bloquante, et que je kill le thread, la fonction SDLNet_TCP_Send continuera de s'ex�cuter (car elle appartient � une DLL)??

Je commence � avoir l'impression que je vais devoir totalement changer d'outils pour le r�seau -- si les fonctions SDL Send et Recv peuvent bloquer longtemps -- car SDL_KillThread n'a pas l'air gentille du tout.

Merci encore de votre aide,

coyotte507

[Spout]

Par exemple si j'utilise la fonction SDLNet_TCP_Send, qui est bloquante, et que je kill le thread, la fonction SDLNet_TCP_Send continuera de s'ex�cuter (car elle appartient � une DLL)??

C'est exactement comme �a que je l'ai compris .

[nicroman]

Une fonction n'est pas un thread....

Bloquant ca veut dire: "attend un signal d'un authre thread quelque part", c'est tout... si ton thread est dans la fonction SDLNet_TCP_Send, et que tu le tues, ben voil�, c'est tout, tu le tues... l'autre thread va bien envoyer son signal, mais y aura personne pour l'�couter.

[3DArchi]

Je ne connait pas SDL mais quelques id�es pour ton probl�me:
-> Plut�t que d'utiliser un brutal KillThread tu peux mettre en place un m�canisme de demande de fermeture de ton thred. Celui-ci peut alors se terminer correctement. A toi de g�rer les blocages.
-> Plut�t que d'avoir des TCPSDLNet_TCP_Send/Rcv en mode bloquant, tu peux t'appuyer sur des sockets non bloquantes et utiliser le select et/ou des API sp�cifiques pour attendre (type WSAWaitForMultipleEvents sur Windows).

[Spout]

Une fonction n'est pas un thread....

Bloquant ca veut dire: "attend un signal d'un authre thread quelque part", c'est tout... si ton thread est dans la fonction SDLNet_TCP_Send, et que tu le tues, ben voil�, c'est tout, tu le tues... l'autre thread va bien envoyer son signal, mais y aura personne pour l'�couter.

Si c'est le thread qui appelle la fonction dans la DLL, (l'ex�cution se trouve alors dans la DLL) et que le thread appelant est kill� pendant ce temps l�, la DLL n'est pas tenue au courant de la mort du thread et continue jusqu'au retour de la fonction de la DLL utilis�e je suppose.
D'o� le probl�me si la fonction est bloquante (sans parler du timeout).

Car un EXE/DLL et une autre DLL sont tout de m�me des "composants" diff�rents qui vivent leur vie chacun de leur c�t�.

[3DArchi]

Si c'est le thread qui appelle la fonction dans la DLL, (l'ex�cution se trouve alors dans la DLL) et que le thread appelant est kill� pendant ce temps l�, la DLL n'est pas tenue au courant de la mort du thread et continue jusqu'au retour de la fonction de la DLL utilis�e je suppose.
D'o� le probl�me si la fonction est bloquante (sans parler du timeout).

Car un EXE/DLL et une autre DLL sont tout de m�me des "composants" diff�rents qui vivent leur vie chacun de leur c�t�.

Euh, t'es s�r de �a. Pour moi, le contexte d'ex�cution est li� � un processus avec ses threads. L'application et les DLL ne sont que du code charg� en m�moire. Si ton thread appelle une fonction dans une DLL, et que ton thread est tu�, alors son ex�cution s'arr�te m�me si le code en cours d'ex�cution �tait celui de la DLL. Le risque que je vois est plut�t li� � la non lib�ration des ressources de ton thread.

[Spout]

Euh, t'es s�r de �a.

Pas compl�tement

Pour moi, le contexte d'ex�cution est li� � un processus avec ses threads. L'application et les DLL ne sont que du code charg� en m�moire. Si ton thread appelle une fonction dans une DLL, et que ton thread est tu�, alors son ex�cution s'arr�te m�me si le code en cours d'ex�cution �tait celui de la DLL.

Je comprends ce que tu veux dire, mais mon doute concerne les DLL avec leur propre classe applicative (par exemple CWinApp des MFC), pas celle qui n'exportent que des fonctions avec une interface C.
Alors comment interpr�tes-tu �a:

DLLs attached to the thread are not notified that the thread is terminating.

Le risque que je vois est plut�t li� � la non lib�ration des ressources de ton thread.

Egalement.

[3DArchi]

Je comprends ce que tu veux dire, mais mon doute concerne les DLL avec leur propre classe applicative (par exemple CWinApp des MFC), pas celle qui n'exportent que des fonctions avec une interface C.

A mon sens, il n'y a pas de cr�ation d'un nouveau process/thread donc l'ex�cution se poursuit dans le contexte actuel. Mais je vois ce que tu veux dire: CWinApp d�rive de CWinThread-> donc cr�ation implicite d'un thread. En fait, il faut passer par CWinThread::CreateThread pour cr�er le thread, l'instanciation d'un CWinThread ne suffit pas. Et �a n'a pas l'air d'�tre le cas. Je ne suis pas s�r de mon coup, mais en croisant diff�rentes infos du MSDN, je persiste � dire qu'il n'y a pas de cr�ation de thread implicite lors du chargement d'une quelconque DLL.

Alors comment interpr�tes-tu �a:

DLLs attached to the thread are not notified that the thread is terminating.

Que tu ne passeras pas par ExitInstance/DllMain(DLL_THREAD_DETACH). Donc, tu auras bien un probl�me de lib�ration de ressources.

[M�dinoc]

Attention, "The system frees the thread's initial stack" signifie que la m�moire brute de la pile dudit thread est lib�r�e. Aucun destructeur n'est appel�...

[Profman]

Un thread est un m�canisme de syst�me d'exploitation pas de liaison direct avec le langage C++ qui lui ne permet pas la gestion des threads (nativement).

En outre la seule fa�on (l�gale) d'appeler un destructeur est d'appeler un des deux op�rateurs du langage C++, soit delete soit delete [] (si le ou les objets ont �t� cr�es avec "new").

Il est donc tr�s probable qu'une API type "KillThread" (que je ne connais pas d'ailleurs) n'appelle jamais un destructeur, et de toute fa�on si elle le faisait, le design de cette architecture serait tr�s contestable.

Dans la plupart des syst�mes � base de threads, quand une de ces unit�s d'ex�cution est d�marr�e une pile est allou�e (de taille d�terminable en g�n�ral). Quand le thread est d�truit la pile est relach�e.

[coyotte507]

Bonsoir

Attention, "The system frees the thread's initial stack" signifie que la m�moire brute de la pile dudit thread est lib�r�e. Aucun destructeur n'est appel�...

C'est ce que j'avais compris aussi ...

J'ai regard� la source de SDL_net (jusqu'o� faut aller faire des v�rifications!) et donc apparement les fonctions SDLNet_TCP_Send et SDLNet_TCP_Recv peuvent s'ex�cuter en un laps de temps assez court, quand on les appelle au bon moment, donc de ce c�t� l� �a va... je les mettrais quand m�me dans un thread, mais j'aurais pas besoin de le tuer.

J'ai compris les risques avec TerminateThread, la prudence exig�e lorsqu'on l'utilise -- je ne connaissais pas les risques d'appeler une fonction DLL, et il n'y a pas de moyen de d�tacher une DLL d'un thread avec SDL uniquement (peut-�tre que sous linux y'a pas ce genre de probl�me ?).

En gros, gr�ce � tous les renseignements obtenus, je pense avoir trouv� le moyen d'impl�menter mon projet, sans changer de biblioth�que

Merci beaucoup � vous tous!

coyotte507

[Jean-Marc.Bourguet]

En outre la seule fa�on (l�gale) d'appeler un destructeur est d'appeler un des deux op�rateurs du langage C++, soit delete soit delete [] (si le ou les objets ont �t� cr�es avec "new").

Depuis quand?

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include <string>
#include <stdlib.h>
#include <iostream>
#include <ostream>
 
using namespace std;
 
int main()
{
   void* ptr = malloc(sizeof(string));
   std::string* bar = new(ptr) string("Hello world\n");
   std::cout << *bar;
   bar->~string();
   free(ptr);
}

me semble parfaitement conforme, aux typos pr�s. C'est la technique utilis�e normalement dans les conteneurs (difficile par exemple d'impl�menter std::vector<T>::reserve() si on ne n'utilise pas).

[Profman]

Depuis quand?

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include <string>
#include <stdlib.h>
#include <iostream>
#include <ostream>
 
using namespace std;
 
int main()
{
   void* ptr = malloc(sizeof(string));
   std::string* bar = new(ptr) string("Hello world\n");
   std::cout << *bar;
   bar->~string();
   free(ptr);
}

me semble parfaitement conforme, aux typos pr�s. C'est la technique utilis�e normalement dans les conteneurs (difficile par exemple d'impl�menter std::vector<T>::reserve() si on ne n'utilise pas).

La franchement c'est ce que j'appel de la grosse bidouille !!

Appeler un destructeur "� la main", evidement on peut mais tr�s dangereux dans un code pro.

De plus je ne vois pas l'int�r�t de ce code : allouer la taille de la string avec "malloc', appeler le destructeur explicitement et lib�rer avec "free" trop fort.

Pourquoi ne pas utiliser que "new" et "delete" c'est fait pour �a : �a alloue et appel les bons m�canismes au bon moment.

[JolyLoic]

Comme indiqu� par Jean-Marc, c'est rare de devoir mettre �a en place, mais �a peut servir. Imagine par exemple qu'avec un seul malloc (ou un new "non typ�") on peut r�server de la place contigu� pour 100 objets, mais ne cr�er qu'un objet dans un premier temps, puis cr�er les autres � la demande, sans plus avoir besoin d'allouer de m�moire. C'est ce que fait std::vector en interne.

Il y a encore une autre fa�on l�gale d'appeler un destructeur, c'est certainement m�me la plus courante :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
{ 
 A a;
} <- Le destructeur de A est appelé...

[Profman]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
{ 
 A a;
} <- Le destructeur de A est appelé...

Hehe oui c'est vrai La pile reste une valeur s�re.

Un autre truc pas mal c'est d'utiliser un smart pointer qui se chargera de faire le delete. Mais c'est vrai que cette b�te l� ne pla�t pas � tous

Ici un exemple avec le smart pointer de boost :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
class X;

int main() {

    boost::scoped_ptr<X> spx( new X() );

    return 1;
} // ici le destructeur de 'spx' entrainera la lib�ration

[Klaim]

Comme indiqu� par Jean-Marc, c'est rare de devoir mettre �a en place, mais �a peut servir. Imagine par exemple qu'avec un seul malloc (ou un new "non typ�") on peut r�server de la place contigu� pour 100 objets, mais ne cr�er qu'un objet dans un premier temps, puis cr�er les autres � la demande, sans plus avoir besoin d'allouer de m�moire.

Pratique tr�s courante dans le d�veloppement de jeu vid�o par exemple, surtout sur console.

[deadalnix]

Une surcharge de new et delete sera plus �l�gante dans une telle situation.

Elle ppurra meme fournir des infos en mode debug.