Discussion :

[poukill]

Bonjour à tous,

Je me demande quelle est la meilleure façon de demander gentiment à un thread de s'arrêter?
Sachant bien sûr qu'on est programmeur du programme appelant ET du thread. C'est à dire que je ne cherche pas à arrêter brutalement un thread, c'est impossible ou pas portable (et pas bien ), mais bien à lui demander d'arrêter sa boucle ou son calcul en cours.

J'en suis pour l'instant au bête booléen must_stop dans le programme appelant (principal) mais c'est pas super élégant. Un event serait un poil mieux à mon goût.

Je suis preneur de vos idées. (j'utilise boost.Thread)



Poukill

[ram-0000]

Moi j'utilise un event, un IOCP ou un mutex, cela dépend des contextes. Enfin un truc sur lequel je peut faire une attente bloquante sans consommer de CPU.

Le booléen "must_stop" + sleep(), je trouve pas cela terrible non plus.

[nicroman]

En fait tout dépend ce que fait ton thread...
Si ton thread a des opérations bloquantes (sockets, attente d'evenements,...) alors oui, le passage par un event systeme est quasi obligatoire (à bas les programmes qui prennent 100% du temps CPU ! )

Si par contre ton thread n'a pas d'opération bloquante (par exemple transcodage d'une vidéo, ou autre), alors un simple booléen partagé peut être suffisant (et pas moins élégant, surtout quant on sait comment sont gérés les events en général ).

[poukill]

Non mon thread n'a pas d'opération bloquante, donc...
Oui, pour l'instant je suis toujours sur mon booléen!

Merci à vous deux, j'essaierai d'effectuer quelques tests dans le futur quand j'aurai le temps, et je reviendrai les poster ici!

A+

Poukill

[loufoque]

Le bon moyen d'annuler un thread est le lancer asynchrone d'exception, ce qui constitue le seul moyen de libérer proprement les ressources.

[white_tentacle]

Le bon moyen d'annuler un thread est le lancer asynchrone d'exception, ce qui constitue le seul moyen de libérer proprement les ressources.

Il me semble bien que non, et même que c'est une erreur (cf pourquoi il ne faut pas utiliser Thread.Abort en C#).

L'idée étant qu'une exception asynchrone pouvant arriver à n'importe quel moment, elle peut arriver lors :
- de la création du thread
- de la mort du thread
- d'une autre exception
- d'une création d'objet, qui se retrouve alors partiellement créé

Le premier cas est peu probable, les autres le sont plus. Le plantage de l'application complète suite à une exception asynchrone n'est pas purement théorique, je l'ai rencontré (en C#) dans une application réelle.

Un bon article là-dessus