Discussion :

[voyageur]

Bonjour,

je suis confronté à un probleme que je n'arrive pas à resoudre.
Je lance un thread qui fais un long traitement qui crée des fichiers et ecrit dedans.
J'arrete le thread en appelant dessus la methode abort(), pas de probleme le thread s'arrete.
Le probleme se pose lorsque je relance le thread, j'ai alors une IO exception, qui me dis que le fichier est utilisé par un autre process.

Code :

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

1
2
3
4
// demarrage et relance du thread
PgbThread = new Thread(new ThreadStart(Treatment));
                PgbThread.IsBackground = true;
                PgbThread.Start();

Code :

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

1
2
// arret du thread
 PgbThread.Abort();

[theMonz31]

C'est normal...

Si tu ouvres le fichier dans ton thread de traitement, Windows ( l'OS) te
reserve un handle de fichier et lors du abort sur ton thread, si tu n'as pas
"fermer" correctement ton fichier (File.Close par exemple) , l'application
va garder le handle sur le fichier et tu auras du mal à écrire dedans par la suite

donc, en regle general, faire un abort sur un thread nécéssite que le thread
se "ferme" correctement si possible

The Monz, toulouse

[voyageur]

donc, en regle general, faire un abort sur un thread nécéssite que le thread
se "ferme" correctement si possible

The Monz, toulouse

c'est a dire ?

[Mose]

C'est à dire que ton fichier il est encore ouvert.
Donc forcément, tu peux pas bosser dessus paske t'as killé ton thread comme un gros crado

"Mais comment on fait alors ?"
Plutôt que de tuer salement un mec qui fait bien gentiment son travail, il suffit dans la boucle principal de ton thread de lui coller un boolean "continuer".
Tant que le boolean est vrai, alors ton thread bosse.
Quand tu mets le booléen à faux, ton thread sais qu'il doit s'arrêter, et là il exécutera le Close() qui va bien pour fermer ton fichier.

[dragohn]

Bonjour,

vaut il mieux utiliser votre solution Mose, ou passer par un bloc try/catch/finally et capturer l'exception ThreadAbortException pour fermer le fichier/finir le traitement.
Ma question peut sembler de novice (je le suis), et je dois admettre que j'avais pensé à traiter ça que via l'exception... à faire ou éviter?

[voyageur]

Bonjour,

vaut il mieux utiliser votre solution Mose, ou passer par un bloc try/catch/finally et capturer l'exception ThreadAbortException pour fermer le fichier/finir le traitement.
Ma question peut sembler de novice (je le suis), et je dois admettre que j'avais pensé à traiter ça que via l'exception... à faire ou éviter?

j'ai egalement essayé de fermer le fichier dans le bloc ThreadAbortException mais ca ne donne rien.

[Mose]

Bonjour,

vaut il mieux utiliser votre solution Mose, ou passer par un bloc try/catch/finally et capturer l'exception ThreadAbortException pour fermer le fichier/finir le traitement.
Ma question peut sembler de novice (je le suis), et je dois admettre que j'avais pensé à traiter ça que via l'exception... à faire ou éviter?

L'exception c'est la solution barbare et un peu crade. qui plus est, en terme de perf c'est pas terrible : le runtime peut mettre une seconde ou deux avant de rendre la main.
La solution du booléan est plus propre, et elle permet à ton thread de finir au moins le traitement qu'il était en train de faire.

Ex : je copie n fichiers dans mon thread. A chaque fichier de vérifie mon booléen.
Si je kill + exception : le ficher en cours de copie a-t-il été complètement copié / partiellement copié / pas du tout copié ? On n'en sait rien
alors qu'avec la solution booléan, le traitement s'interromp après la copie complète d'une fichier

[voyageur]

C'est à dire que ton fichier il est encore ouvert.
Donc forcément, tu peux pas bosser dessus paske t'as killé ton thread comme un gros crado

"Mais comment on fait alors ?"
Plutôt que de tuer salement un mec qui fait bien gentiment son travail, il suffit dans la boucle principal de ton thread de lui coller un boolean "continuer".
Tant que le boolean est vrai, alors ton thread bosse.
Quand tu mets le booléen à faux, ton thread sais qu'il doit s'arrêter, et là il exécutera le Close() qui va bien pour fermer ton fichier.

j'ai essayé cette technique mais le probleme est que le thread est arreté à la premiere rentrée dans la boucle, il n'a donc pas acces à l'etat du booleen.
Comme ca :

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
while (termine == false){
 
       //.... traitement
      // 1ere boucle for
      for (...){
 
 
      }
 
       //.... traitement
      // 2e boucle for
      for (...){             // <--- si le thread s'arrete ici l'etat termine n'a pas changé
 
 
      }
 
 
      //.... traitement
      // 3e boucle for
      for (...){
 
 
      }
 
 
 
}

Je pourrais verifier l'etat de "termine" avant chaque instruction mais le traitement fais des centaines de lignes, je ne me vois pas faire ca 700 fois !!

Si quelq'un a une astuce je suis preneur

[Mose]

j'ai essayé cette technique mais le probleme est que le thread est arreté à la premiere rentrée dans la boucle, il n'a donc pas acces à l'etat du booleen.

Quand tu me dit "le thread s'arrête ici", j'ai un peu de mal à comprendre.. qui l'arrête ?

Je me suis sans doute mal exprimé.
En fait, pour arrêter ton thread, tu n'a qu'une seule chose à faire : mettre le booléan terminé à vrai.

Ensuite, il ne s'agit pas de créer une boucle spécialement pour ça. Je partais du principe que ton thread fonctionnait déjà avec une boucle. Dans ton exemple, il s'agit de tes boucles for.

Dans chacune de ces boucles, tu rajoutes la condition d'arrêt !termine (ça retourne déjà un booléan, pas la peine de faire termine == false)

Code :

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

1
2
for(int i = 0; (i < max) && !termine; i++)
{...}

Je pourrais verifier l'etat de "termine" avant chaque instruction mais le traitement fais des centaines de lignes, je ne me vois pas faire ca 700 fois !!

En fait, tu peux ne faire ça qu'à certaines étapes clef.
Par exemple, avant tous les traitements longs.