[C#] Thread, FileStream et Stream

Dev
1

j’ai ce bout de code:

while ((bytesRead = fileStream.Read(buffer, 0, buffer.Length)) != 0)                {                    SentSize += bytesRead;                    Thread.Sleep(10);                    requestStream.Write(buffer, 0, bytesRead);                }

dans un thread. Quand je tente un Thread.Abort(); aucune exception ThreadAbortedException est droppée quand je me trouve dans cette boucle (j’ai foutu un point d’arret dans l’exception)

J’ai testé avec un:

while(true);

par curiosité, mais ca ne fait rien plantouiller (en gros le thread s’arrêe correctement, l’exception est bien droppée). Pour information, le requestStream est un Stream d’un HttpWebRequest (cette boucle sert a uploader un fichier par HTTP Post).

Help, je deviens fou je comprends pas pourquoi ca merde. :stuck_out_tongue:

2

C’est mal d’utiliser Thread.Abort pour arreter un thread pour tout un tas de raisons. Cherche “thread.abort is evil” sur google pour comprendre pourquoi c’est vraiment une solution de derniere chance.

Aussi a noter que l’exception ne peut etre levee qu’a partir du moment ou le CLR reprend la main, si un appel natif est bloquant, il n’y aura pas d’exception avant que l’appel bloquant se debloque.

Enfin, encore une fois, a priori, c’est pas comme ca qu’il faut arreter un autre thread.

3

Mmm alors il faut que je fasse des appels non bloquants en écriture? Parce que je vois pas ce qui peut bloquer mon thread la… l’écriture de 4kos sur une interface TCP ca prend quand meme pas tellement de temps?

Ps: le Thread.Abort, c’est l’utilisateur qui annule l’envoi… Tu penses que ca serait mieux, si je rajoutes une condition dans ma boucle, comme ca:

while (((bytesRead = fileStream.Read(buffer, 0, buffer.Length)) != 0) && (!SequenceAborted))

ou SequenceAborted est un booléen qui est mis a true quand l’utilisateur cliques sur le bouton Annuler.

A sinon, totalement hors sujet, je suis de plus en plus fan de la “logique” de programmation de CSharp. C’est d’une simplicité à toute épreuve quand on connait le monde de l’objet (je me demande même comment j’arrivais a programmer en Visual Basic 6.0).

4

J’avais à peu près le même problème, et sachant qu’il ne fallait absolument pas faire de Thread.Abort(), j’ai passé dans mon thread un ManualResetEvent correspondant à une demande d’arrêt.

Il est testé dans la boucle dans ce style là pour sortir si mon ManualResetEvent est setté.

StopEvent étant le nom de mon ManualResetEvent.

Si ça peut aider.

5

Bah moi j’ai rajouté un booléen supplémentaire de test dans mon while ca passe au poil :P.

6

Question bête…
Le Thread.Abort est-il la seule solution quand le thread est bloqué sur une méthode de connexion “receive” ?

7

Euhh… il faut que la CLR ai la main pour aborter un Thread. Vu que le receive est bloquand, le CLR n’a pas la main… eh ouais c’est con mais c’est comme ca…