Discussion :

[Finality]

Bonjour tout le monde,

je viens vous voir aujourd'hui pour un petit problème tout bête mais dont je trouve pas comment m'en sortir.

Prenons un exemple très simple. Je propose à l'utilisateur une liste de départements. Dès qu'il choisit un département, je lance un thread qui va rechercher toutes les villes de ce département.

Le problème, c'est que si pendant un thread tourne l'utilisateur choisit un autre traitement, un deuxième thread est lancé mais le premier tourne toujours.

J'aimerai donc au moment du lancement du second thread pourvoir stopper le premier. Auriez-vous une idée de comment faire ?

Merci d'avance

[DotNetMatt]

Il y a plusieurs façons de faire, selon ce que tu utilises

Quelle version du Framework utilises-tu ?

Est-ce que tu utilises des Tasks ? Ou des BackgroundWorkers ? Ou des Threads classiques ?

[Finality]

Alors j'utilise le Framework 4.0 avec des Threads classiques (je ne peux pas changer la version du framework mais je peux bosser sur autre chose que les threads si nécessaire :p )

[DotNetMatt]

Ok merci pour ces précisions ! Personnellement j'ai plus d'expérience avec les tasks, et j'utilise le "Cancellation Framework", qui est assez simple à utiliser et à comprendre (il suffit de lire un peu la MSDN).

Sinon, tu peux utiliser une variable volatile de type bool afin de gérer l'exécution des threads. Voici une discussion assez complète sur le sujet : http://stackoverflow.com/questions/3...another-thread

[Pol63]

3 méthodes
la bien mais pas toujours utilisable c'est d'avoir un booléen comme dit précédemment, mais c'est pratique quand on a une boucle (pour pouvoir vérifier le booléen souvent et sortir du void)
la moins bien c'est .abort sur le thread, ca déclenche une exception qui se propage à travers tous les catchs apparemment, donc ca arrete le thread, par contre le premier throw peut se trouver dans le framework, voir s'il n'y a pas d'effets de bords ...
la 3ème je ne sais pas trop quoi en penser c'est .interrupt sur le thread, là ca arrête le thread où il en était directement ...

[giova_fr]

d'après un bouquin que j'avais lu, le abort est à éviter à tout prix, sauf en ultime recourt. Je ne me rappelle plus dans le détail mais ça n'était pas qu'une question d'exception.

Je crois que le interrupt est très proche du abort mais ne lève pas d'exception.

A ma connaissance il n'y a pas d'autre choix que celui du booléen qu'on interroge régulièrement. J'ai personnellement une préférence pour le Cancel du BackgroundWorker.

Edit : je viens de voir dans mon bouquin, le FrameWork 4 propose CancellationToken et CancellationTokenSource. Ca peut valoir le coup d'oeuil...

[Pol63]

il y a une différence entre abort et interrupt au moins au niveau de ce qu'il se passe
après le booléen comme je disais ne fonctionne pas dans tous les cas, si dans le thread tu appelles juste une procédure stockée de 3 minutes, il faudra passer par abort ou interrupt ...

[giova_fr]

justement CancellationToken semble permettre d'arretter le thread de façon managé même dans le cas que tu viens de donner.

source : http://msdn.microsoft.com/fr-fr/library/dd997364.aspx voir la section "Écoute en inscrivant un rappel".

C'est bête je n'ai plus le texte que j'avais lu concernant Abort, en gros ça disait que ça n'était pas très bon pour le CLR pour nettoyer certaines choses, l'auteur avait pondu toute une page à ce sujet...

[Pol63]

justement CancellationToken semble permettre d'arretter le thread de façon managé

je viens de lire le lien, c'est exactement le même principe que le booléen, dans les exemples donnés ils vérifient un booléen sur une instance mais dans une boucle ...

pour arrêter un thread qui fait une exécution longue sans boucle je pense donc qu'il n'y a pas d'autres choix que abort ou interrupt, ou alors de mieux coder pour appeler plusieurs petites parties

[Finality]

Bonjour tout le monde,

merci à tous pour votre aide. Je viens de tester le Interrupt et le problème est que le thread va jusqu'au bout quand même. Est-ce normal ?

[DotNetMatt]

D'après la MSDN, c'est normal :

Si ce thread n'est pas actuellement bloqué à l'état d'attente, de veille ou de jointure, il sera interrompu dès qu'il commencera à bloquer.Une ThreadInterruptedException est levée dans le thread interrompu, mais seulement une fois que le thread est bloqué.Si le thread ne bloque jamais, l'exception n'est jamais levée et le thread peut donc se terminer sans jamais être interrompu.

Source : http://msdn.microsoft.com/fr-fr/libr...interrupt.aspx


Voici une lecture intéressante sur l'arrêt des Threads : http://stackoverflow.com/questions/3...632642#3632642

[antoine.debyser]

Bonjour,

Si "Abort" est déconseilé, c'est parce que cette exception ce comporte différement des autres. Il me semble qu'elle bypass les clauses finally, et du coup il se peut que les ressources non managé ne soit pas liberer. Ce point est à verifier.

EDIT:
D'apres la msdn Le comportement lié au finally, partialement executé, serait propre à version 1.x du Framework. Par contre, la msdn evoque le problème des constructeurs statiques, qui ne semble toujours pas résolu.

[morgand]

Tu devrais t'orienter plutôt vers un marqueur d'arrêt ...

Qui démarre le deuxième thread ? comment ça se passe ? peux tu donner un peu plus d'élément ?