Discussion :

[invoceusse]

Salut a tous,

Actuellement l'IHM de commande en winform C++/CLI pour mon projet marche nickel, le seul problème arrive quand je doit fermer mon application, a ce moment le thread démon (un thread pour surveiller la réception de message) se ferme mal et provoque donc un thread zombie (thread qui continue de consommer les ressources de l'ordinateur alors que son process est fermer).

Pour plus de précision mon Thread possède une boucle while avec un booléen, dans cette fonction j'ai la réception d'un message d'une socket et donc cela bloque sur cet instruction. (pour la socket je suis ici le client)

Je peut donc essayer d'intervenir a plusieurs niveau quand j'appelle la fonction de fermeture de la winform:

• Fermer la socket puis le thread
• mettre un time-out sur la socket
• envoyer un message depuis le client sur la socket sortir de la boucle

J'ai déjà essayer la première solution et je ne l'ai pas réussit...

Je ne vois pas contre pas comment pas comment générer un time-out sur une réception de message ni comment envoyer un message à la socket client depuis le client....

La seul solution viable que je verrais serais d'envoyer au serveur que je veut partir et qu'il m’envoie une instruction pour pouvoir quitter l'instruction bloquante en passant le booléen à false, mais cela ne marcherais alors que dans le cas ou le serveur est encore connecter...

[bacelar]

>thread zombie (thread qui continue de consommer les ressources de l'ordinateur alors que son process est fermer).
LOL, vous êtes allé chercher ce dahu où ?
Un thread, même un thread système, est toujours dans un processus (bon les threads système passe d'un processus à un autre sans autre forme de procès).

En .NET, un thread est toujours dans un AppDomain et un Appdomain est circonscrit à un processus du système.

Vous n'avez donc pas un "thread zombie", vous avez tout simplement merdé dans l'architecture de votre application et elle est tanquée parce qu'un thread non marqué comme d'arrière-plan n'est toujours pas fini.

Je vois plein de solution, donc les meilleures sont de revoir votre architecture.

Comme le fait que le thread soit natif ou un thread .NET est discriminant dans les solutions au problème, merci de nous donnez l'info, svp.

Vous utilisez quoi comme API pour que votre écoute ne soit pas alertable sur un handle que votre thread d'IHM utiliserait pour demander à ces copains de foutre le camps ???

[Médinoc]

>thread zombie (thread qui continue de consommer les ressources de l'ordinateur alors que son process est fermer).
LOL, vous êtes allé chercher ce dahu où ?

Ici, peut-être (mais c'est quand même mal exprimé, parce qu'alors c'est tout le processus qui est zombi).

[invoceusse]

>thread zombie (thread qui continue de consommer les ressources de l'ordinateur alors que son process est fermer).
LOL, vous êtes allé chercher ce dahu où ?

Ou j'ai été le chercher? mon prof d'info qui me la dit quand il nous a expliquer les thread x)

Vous n'avez donc pas un "thread zombie", vous avez tout simplement merdé dans l'architecture de votre application et elle est tanquée parce qu'un thread non marqué comme d'arrière-plan n'est toujours pas fini.

Non l'architecture de l'application est bonne je crois, mais je sais que mes threads sont pas fini justement car je suis sur une instruction bloquante DANS le thread, mon principal soucie viens pas du thread enfaite (du moins pour l'instant) mais de la socket DANS le thread que j'aimerais fermer...

Comme le fait que le thread soit natif ou un thread .NET est discriminant dans les solutions au problème, merci de nous donnez l'info, svp.

Vous utilisez quoi comme API pour que votre écoute ne soit pas alertable sur un handle que votre thread d'IHM utiliserait pour demander à ces copains de foutre le camps ???

Bon soit je suis un abruti soit j'ai rien dormi durant ce cours mais la j'arrive pas à comprendre °°

[bacelar]

Ou j'ai été le chercher? mon prof d'info qui me la dit quand il nous a expliquer les thread x)

Oui, il a bon dos le prof, je crois, sur ce coup là. N'auriez-vous pas confondu thread zombie et processus zombies ?

Non l'architecture de l'application est bonne je crois,

LOL, pas pire aveugle que ...

Vous êtes dans cette situation car votre architecture est foireuse, un point c'est tout.
Vous ne devez JAMAIS utiliser de primitives bloquantes dans un working thread sans utiliser une handle de réveil activable par le thread principal, JAMAIS.
Votre remarque est aussi ridicule que dire qu'un avion sans train d'atterrissage n'a pas de problème d'architecture car il peut voler (si vous faite dans de l'hydravion, faudrait nous prévenir).

Vous pouvez utiliser les fonctionnalités de background-threading de .NET pour continuer à programmer comme un sagouin : http://msdn.microsoft.com/en-us/libr...tudio/hybbz6ke
Mais la mécanique derrière est loin d'être trivial, vous ne ferez pas pareil avec un truc pensé sur un coin de table.

mon principal soucie viens pas du thread enfaite (du moins pour l'instant) mais de la socket DANS le thread que j'aimerais fermer

On prend jamais un os dans la gueule d'un chien, laissez votre thread satellite fermer la socket, faut juste le prévenir, avec un canal de communication que vous auriez dû concevoir AVANT, monsieur le dormeur.
Par exemple avec une variable partagé ET un handle de réveil/déblocage du thread satellite.

Bon soit je suis un abruti soit j'ai rien dormi durant ce cours mais la j'arrive pas à comprendre °°

Rassure-toi, on a tous galéré avec le multi-threading, mais faut pas être butté.

Donc répondez aux questions SVP :

Comme le fait que le thread soit natif ou un thread .NET est discriminant dans les solutions au problème, merci de nous donnez l'info, svp.

Vous utilisez quoi comme API pour que votre écoute ne soit pas alertable sur un handle que votre thread d'IHM utiliserait pour demander à ces copains de foutre le camps ???

[Médinoc]

En fait en .Net, on peut utiliser les sockets directement de manière asynchrone, avec des méthodes comme BeginAccept() et BeginReceive(). Et cela peut se cumuler avec les fonctions d'attente, vu que le IAsyncResult retourné contient un WaitHandle.

On peut en générer plusieurs d'un coup avec la méthode WaitHandle.WaitAny(), à laquelle on peut ajouter des événements, etc.

[bacelar]

Médinoc, j'ai pas dit que si t'es au .NET, t'es obligé de programmer comme un sagouin.
On peut aussi programmer proprement en .NET en utilisant tout ces trucs, et bien d'autres.

Mais pour ça, faut admettre qu'il a un peu merdu sur sa conception.

[invoceusse]

Oui, il a bon dos le prof, je crois, sur ce coup là. N'auriez-vous pas confondu thread zombie et processus zombies ?

Possible, °° Après le problème n'est pas dans la terminologie mais dans mon code xD

Vous êtes dans cette situation car votre architecture est foireuse, un point c'est tout.
Vous ne devez JAMAIS utiliser de primitives bloquantes dans un working thread sans utiliser une handle de réveil activable par le thread principal, JAMAIS.

Je comprend mieux! mais dans se cas je ne vois pas comment avoir se handle de reveil...

On prend jamais un os dans la gueule d'un chien, laissez votre thread satellite fermer la socket, faut juste le prévenir, avec un canal de communication que vous auriez dû concevoir AVANT, monsieur le dormeur.
Par exemple avec une variable partagé ET un handle de réveil/déblocage du thread satellite.

Canal de communication?! Une zone de donnée partager?

Mais sinon il me semble que j'ai déjà une variable partager pour le thread, mais je sais pas faire le handle de réveil.

Rassure-toi, on a tous galéré avec le multi-threading, mais faut pas être butté.

Je demande qu'a apprendre et au pire a corriger les erreurs que j'ai pu apprendre.

Donc répondez aux questions SVP :

Comme le fait que le thread soit natif ou un thread .NET est discriminant dans les solutions au problème, merci de nous donnez l'info, svp.

Vous utilisez quoi comme API pour que votre écoute ne soit pas alertable sur un handle que votre thread d'IHM utiliserait pour demander à ces copains de foutre le camps ???

Je veut bien! mais je ne sais pas la différence entre les termes mais je vais essayer.

Pour les thread j'ai utiliser ceux la http://dotnet.developpez.com/faq/cpp...hreadparameter donc cela doit être du .net

Je programme actuellement sur visual studio 2012, et je doit pouvoir faire un handle alertable, mais je n'ai aucune idée de comment faire...

[bacelar]

Are you kidding me ? !

http://dotnet.developpez.com/faq/cpp...ing#stopthread