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�.