1. Je ferme le socket (dois-je mettre en place un mutex (lock(this))
pour le fermer ?)
2. Je 'tue' le thread.
3. L'affichage se fait bien.
4. l'application disparait du systray mais je vois tout de même une
instance dans le gestionnaire des tâches.
Je ne comprends pas pourquoi je vois toujours le processus... un
ServerThread.IsAlive me retourne false après le .Abort()...
Je vous conseil de demander, via un mécanisme quelconque, à votre thread d'écoute de se terminer plutôt que de le détruire violemment.
-- Paul Bacelar
"Delf" wrote in message news:42a805ae$0$19200$
Delf wrote:
> [...]
Précision : celà arrive 1 fois sur 10 environ ; ce n'est pas systématique.
-- Delf
Paul Bacelar
"Delf" wrote in message news:42a80f65$0$19226$
Delf wrote:
> [...]
J'ai mis l'attribut IsBackground à true.
Difficile de savoir si ça aura une répercussion...
-- Delf
Cela permet au programme de mourir lors de la fin du thread principal sans attendre la fin des threads satellites (avec IsBackground à true) mais ne vous exonère pas de leur demander gentiment de se terminer sous peine de lancement d'exceptions fatales.
-- Paul Bacelar
"Delf" <abuse@wanadoo.fr> wrote in message
news:42a80f65$0$19226$636a15ce@news.free.fr...
Delf wrote:
> [...]
J'ai mis l'attribut IsBackground à true.
Difficile de savoir si ça aura une répercussion...
--
Delf
Cela permet au programme de mourir lors de la fin du thread principal sans
attendre la fin des threads satellites (avec IsBackground à true) mais ne
vous exonère pas de leur demander gentiment de se terminer sous peine de
lancement d'exceptions fatales.
Difficile de savoir si ça aura une répercussion...
-- Delf
Cela permet au programme de mourir lors de la fin du thread principal sans attendre la fin des threads satellites (avec IsBackground à true) mais ne vous exonère pas de leur demander gentiment de se terminer sous peine de lancement d'exceptions fatales.
-- Paul Bacelar
Delf
Paul Bacelar wrote:
Je vous conseil de demander, via un mécanisme quelconque, à votre thread d'écoute de se terminer plutôt que de le détruire violemment.
Mes threads sont en boucle infinie faire un traitement toutes les X minutes.
Pour l'instant, j'utilise une méthode qui invoque Abord() sur les threads quand l'utilisateur souhaite quitter l'application le tout encadré pat un try/catch. Exemple :
Est-ce valable ? Apparemment, l'application se ferme à 'chaque fois' correctement. Je voudrais savoir si cette façon de procéder est propre. Merci.
-- Delf
Paul Bacelar wrote:
Je vous conseil de demander, via un mécanisme quelconque, à votre thread
d'écoute de se terminer plutôt que de le détruire violemment.
Mes threads sont en boucle infinie faire un traitement toutes les X minutes.
Pour l'instant, j'utilise une méthode qui invoque Abord() sur les
threads quand l'utilisateur souhaite quitter l'application le tout
encadré pat un try/catch. Exemple :
Je vous conseil de demander, via un mécanisme quelconque, à votre thread d'écoute de se terminer plutôt que de le détruire violemment.
Mes threads sont en boucle infinie faire un traitement toutes les X minutes.
Pour l'instant, j'utilise une méthode qui invoque Abord() sur les threads quand l'utilisateur souhaite quitter l'application le tout encadré pat un try/catch. Exemple :
Est-ce valable ? Apparemment, l'application se ferme à 'chaque fois' correctement. Je voudrais savoir si cette façon de procéder est propre. Merci.
-- Delf
Paul Bacelar
"Delf" wrote in message news:42b014c8$0$11284$
Paul Bacelar wrote:
> Je vous conseil de demander, via un mécanisme quelconque, à votre thread > d'écoute de se terminer plutôt que de le détruire violemment.
Mes threads sont en boucle infinie faire un traitement toutes les X
minutes.
Pour l'instant, j'utilise une méthode qui invoque Abord() sur les threads quand l'utilisateur souhaite quitter l'application le tout encadré pat un try/catch. Exemple :
Est-ce valable ? Apparemment, l'application se ferme à 'chaque fois' correctement. Je voudrais savoir si cette façon de procéder est propre. Merci.
-- Delf
Non, car pour qu'un thread, qui reçoit de manière totalement asynchrone une exception (induit par l'utilisation de Abort) libère correctement ses ressources et laisse les structures de données partagées ou sauvegardées dans un état cohérent, il faut faire un travail de codage défensif (ou paranoïaque ;-) ) extrêmement complexe qui ne se justifie que sur des applications ayant des contraintes en temps de réponses bornée proche du temps réels non stricte.
Je vous conseil une approche bien plus pacifique,
http://msdn.microsoft.com/msdnmag/issues/04/10/NetMatters/ -- Paul Bacelar
"Delf" <abuse@wanadoo.fr> wrote in message
news:42b014c8$0$11284$636a15ce@news.free.fr...
Paul Bacelar wrote:
> Je vous conseil de demander, via un mécanisme quelconque, à votre thread
> d'écoute de se terminer plutôt que de le détruire violemment.
Mes threads sont en boucle infinie faire un traitement toutes les X
minutes.
Pour l'instant, j'utilise une méthode qui invoque Abord() sur les
threads quand l'utilisateur souhaite quitter l'application le tout
encadré pat un try/catch. Exemple :
Est-ce valable ? Apparemment, l'application se ferme à 'chaque fois'
correctement. Je voudrais savoir si cette façon de procéder est propre.
Merci.
--
Delf
Non, car pour qu'un thread, qui reçoit de manière totalement asynchrone une
exception (induit par l'utilisation de Abort) libère correctement ses
ressources et laisse les structures de données partagées ou sauvegardées
dans un état cohérent, il faut faire un travail de codage défensif (ou
paranoïaque ;-) ) extrêmement complexe qui ne se justifie que sur des
applications ayant des contraintes en temps de réponses bornée proche du
temps réels non stricte.
Je vous conseil une approche bien plus pacifique,
http://msdn.microsoft.com/msdnmag/issues/04/10/NetMatters/
--
Paul Bacelar
> Je vous conseil de demander, via un mécanisme quelconque, à votre thread > d'écoute de se terminer plutôt que de le détruire violemment.
Mes threads sont en boucle infinie faire un traitement toutes les X
minutes.
Pour l'instant, j'utilise une méthode qui invoque Abord() sur les threads quand l'utilisateur souhaite quitter l'application le tout encadré pat un try/catch. Exemple :
Est-ce valable ? Apparemment, l'application se ferme à 'chaque fois' correctement. Je voudrais savoir si cette façon de procéder est propre. Merci.
-- Delf
Non, car pour qu'un thread, qui reçoit de manière totalement asynchrone une exception (induit par l'utilisation de Abort) libère correctement ses ressources et laisse les structures de données partagées ou sauvegardées dans un état cohérent, il faut faire un travail de codage défensif (ou paranoïaque ;-) ) extrêmement complexe qui ne se justifie que sur des applications ayant des contraintes en temps de réponses bornée proche du temps réels non stricte.
Je vous conseil une approche bien plus pacifique,
http://msdn.microsoft.com/msdnmag/issues/04/10/NetMatters/ -- Paul Bacelar
adebaene
Delf a écrit :
Paul Bacelar wrote:
> Je vous conseil de demander, via un mécanisme quelconque, à votre t hread > d'écoute de se terminer plutôt que de le détruire violemment.
Mes threads sont en boucle infinie faire un traitement toutes les X minut es.
Alors il faut changer le mécanisme d'attente de cette boucle infinie de manière à ce que le thread ouvrier puisse être notifié qu'il doit se terminer (le plus souvent, ca passe par un ManualResetEvent). Dans tous les cas de threads ouvriers travaillant en tache de fond, ce n'est pas la boucle de travail elle-même qui est compliquée, c'est le mécanisme de sortie "propre" du thread.
<snip> catch (Exception) {} <snip>
On ne doit *JAMAIS* utiliser ce genre de code où l'on avale silencieusement une exception sans s'en préoccuper (ni m^me la tracer!)!! En clair, ca veut dire "j'ai un gros bug dans mon application, mais je le pousse discrètement sous la moquette et je fais comme s'il n'existait pas"....
Est-ce valable ? Apparemment, l'application se ferme à 'chaque fois' correctement. Je voudrais savoir si cette façon de procéder est propr e.
Absolument pas!
Arnaud MVP - VC
Delf a écrit :
Paul Bacelar wrote:
> Je vous conseil de demander, via un mécanisme quelconque, à votre t hread
> d'écoute de se terminer plutôt que de le détruire violemment.
Mes threads sont en boucle infinie faire un traitement toutes les X minut es.
Alors il faut changer le mécanisme d'attente de cette boucle infinie
de manière à ce que le thread ouvrier puisse être notifié qu'il
doit se terminer (le plus souvent, ca passe par un ManualResetEvent).
Dans tous les cas de threads ouvriers travaillant en tache de fond, ce
n'est pas la boucle de travail elle-même qui est compliquée, c'est le
mécanisme de sortie "propre" du thread.
<snip>
catch (Exception) {}
<snip>
On ne doit *JAMAIS* utiliser ce genre de code où l'on avale
silencieusement une exception sans s'en préoccuper (ni m^me la
tracer!)!!
En clair, ca veut dire "j'ai un gros bug dans mon application, mais je
le pousse discrètement sous la moquette et je fais comme s'il
n'existait pas"....
Est-ce valable ? Apparemment, l'application se ferme à 'chaque fois'
correctement. Je voudrais savoir si cette façon de procéder est propr e.
> Je vous conseil de demander, via un mécanisme quelconque, à votre t hread > d'écoute de se terminer plutôt que de le détruire violemment.
Mes threads sont en boucle infinie faire un traitement toutes les X minut es.
Alors il faut changer le mécanisme d'attente de cette boucle infinie de manière à ce que le thread ouvrier puisse être notifié qu'il doit se terminer (le plus souvent, ca passe par un ManualResetEvent). Dans tous les cas de threads ouvriers travaillant en tache de fond, ce n'est pas la boucle de travail elle-même qui est compliquée, c'est le mécanisme de sortie "propre" du thread.
<snip> catch (Exception) {} <snip>
On ne doit *JAMAIS* utiliser ce genre de code où l'on avale silencieusement une exception sans s'en préoccuper (ni m^me la tracer!)!! En clair, ca veut dire "j'ai un gros bug dans mon application, mais je le pousse discrètement sous la moquette et je fais comme s'il n'existait pas"....
Est-ce valable ? Apparemment, l'application se ferme à 'chaque fois' correctement. Je voudrais savoir si cette façon de procéder est propr e.
