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