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.