[thread] Stopper un thread

Bonjour à tous,

Je me demande quelle est la meilleure façon de demander gentiment à un thread de s'arrêter? :koi:
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)

:merci:

Poukill

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.

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 ! :D)

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 ;) ).

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

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.

Citation:

---

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

Citation:

---

Although saying “any instruction” is a bit of an overstatement. We don’t process thread aborts if you’re executing inside a Constrained Execution Region (CER), finally block, catch block, .cctor, or while running inside unmanaged code. If an abort is requested while inside one of these regions, we process it as soon as you exit (assuming you’re not nested inside another)

---

C'est déjà ça. Pendant un moment, j'ai eu peur.

Edit:
Par contre, ceci:

Citation:

---

It’s safe to assume that, if code is subject to a thread abort, it will be shortly followed by an AD unload.

---

C'est complètement faux dès qu'on fait du développement Web. ASP.Net possède une facheuse tendance à aborter les threads dès qu'un timeout est écoulé, ce qui est particulièrement horripilant quand il te fait ça pendant un débogage :evilred: ...

Edit2: En fait, c'est génial, ASP.Net semble faire exactement ce qu'un gars de l'équipe .Net même a recommandé de ne pas faire. Raymond Chen avait raison.