Discussion :

[S-prit]

Bonjour,
je développe une classe C++ pour gérer les threads (interfaçant les API WIn32).
J'aurai besoin de plusieurs petites précisions pour le nettoyage à faire après la fin d'un thread et de l'utilisation de l'API CloseHandle.

1. Après le kill d'un thread par l'API "TerminateThread", est-il nécessaire d'utiliser CloseHandle sur le handle du thread ?

2. Le thread se termine de lui-même (il a terminé ce qu'il avait à faire) peut-il lui-même appelé la fonction CloseHandle juste avant de terminer ?

Exemple :

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// Launch-Start thread
HANDLE	classThread::launch(void)
		{
		if(this->status != THREAD_NOT_RUNNING)		return this->handle;
 
		// Create thread & return handle
		this->handle	= CreateThread(NULL, NULL, (LPTHREAD_START_ROUTINE)_threadFn, (LPVOID)this, NULL, &this->_id);
 
		return this->handle;
		}
 
// Main thread function
UINT32	classThread::_threadFn(void * lParam)
		{
		classThread &thread = (classThread&)lParam;
 
		// Change status
		thread.status		= THREAD_RUNNING;
 
		// Execute main function
		thread.mainFn();
 
		// Clean up
		CloseHandle(thread.handle);
		thread.handle  = NULL;
 
		// Change status
		thread.status		= THREAD_NOT_RUNNING;
 
		return 0;
		}

Merci.

[screetch]

etant donné les problemes de leak engendrés par terminatethread, je ne vois pas pourquoi tu te soucies du handle. Ton thread a probablement oublié de relacher sa mémoire, voire même un mutex...

quant à closehandle sur lui même, je pense que c'est possible, mais je ne suis pas certain.

[S-prit]

Etant donné que le thread est encapsulé dans une classe, je n'ai aucun problème de fuite mémoire si je tue le thread avec TerminateThread.

La fonction principale du thread au pire des cas fait des réallocation mémoire, donc si le thread ne sort pas proprement, le destructeur de la classe se chargera de faire le ménage ainsi que le déverrouillage de tous les éléments nécessaires à la synchronisation.

On peut très bien imaginer le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
pThread = new classThread();// Appel au constructeur - allocation mémoire
 
pThread->launch();// Boucle principale, calculs longs
pThread->kill();// Kill - sortie aléatoire dans le thread
 
delete pThread;// Appel au destructeur - libération mémoire - dévérouillage des mutex et autres

Comme j'ai besoin de réactivité et que la boucle principale fait des calculs longs, je veux avoir une fonction de kill sous la main qui me donne le plus de réactivité possible, mais ce n'est pas pour autant que je veux laisser le souk en mémoire (d'où l'utilisation de CloseHandle).

[white_tentacle]

Etant donné que le thread est encapsulé dans une classe, je n'ai aucun problème de fuite mémoire si je tue le thread avec TerminateThread

Ça ça me semble très vite dit.

Sinon, d'après la doc, il faut que tu fermes le handle explicitement (même si ce n'est pas explicite dans la doc).

[S-prit]

Alors normalement, j'utilise une classe dérivée de la classe classThread de cette manière :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
class classThreadDecoder : public classThread
	{
	// Blabla
	}

Et je fais les allocations ainsi que les libérations de ce qui est utilisé dans la boucle principale du thread dans le constructeur et le destructeur :

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
16
17
18
19
20
21
22
classThreadDecoder::classThreadDecoder(void)
	{
	this->decoder		= new classDecoder();
	}
 
 
classThreadDecoder::~classThreadDecoder(void)
	{
	if(this->decoder)	delete this->decoder;
	}
/* CONSTRUCTOR-DESTRUCTOR */
 
 
/* OTHER FUNCTIONS */
void		classThreadDecoder::mainFn(void)
	{
	UINT64		itemToCompute;
 
	itemToCompute = this->decoder->getItemValue();
 
	this->decoder->decode(itemToCompute);
	}

Est ce que la variable itemToCompute peut constituer une fuite mémoire si je tue mon thread comme un sauvage ?
Et est ce que les variables internes utilisées dans par exemple les fonctions decoder::getItemValue() ou decoder::decode() peuvent être des fuites mémoires ?
Sachant que je vais appeler ensuite les destructeurs et que je vais utiliser CloseHandle sur les thread