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

[M�dinoc]

Joli article.

J'ai du mal � comprendre par contre, pourquoi ils utilisent un AutoResetEvent au lieu d'un ManualResetEvent. G�n�ralement, depuis cet article, j'�vite de les utiliser, leur pr�f�rant les ManualResetEvent (que je maitrise mieux) ou vrais s�maphores selon la situation.

Un autre truc � savoir aussi, c'est que Tempo ici n'est pas "un temps de calcul limite" mais une tempo qui sera attendue enti�rement � chaque it�ration (sauf celle qui interrompt le thread). G�n�ralement pour ce genre de travail, on a plus vite fait d'utiliser une tempo nulle (et r�duire la priorit� du thread de travail).

[invoceusse]

Are you kidding me ? !

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

Ben justement le probl�me c'est que j'ai beau utiliser un thread->Abort(); ou un thread->Join(); voir de changer l'�tat du bool�en, je reste toujours sur l'instruction socket->recv() et c'est cette ligne qui bloque quand je doit fermer le programme!

[bacelar]

Bon, �a sent le code Frankenstein, ton application super bien architectur�e de la mort qui tue.

Ton objet "socket" est de quel type.
Celui l� ? : http://msdn.microsoft.com/fr-fr/libr...v=vs.110).aspx

Alors la m�thode propre :
http://msdn.microsoft.com/fr-fr/libr...v=vs.110).aspx

Mais j'ai comme le pressentiment que c'�tait trop simple pour cette application si bien architectur�e.

Si vous ne pouvez pas vous servir de ce type, pourquoi ?

[invoceusse]

Bon, �a sent le code Frankenstein, ton application super bien architectur�e de la mort qui tue.

Jamais dit qu'elle �tait bien architectur�e mais que je PENSAIS qu'elle l'�tais! ^^"

Ton objet "socket" est de quel type.
Celui l� ? : http://msdn.microsoft.com/fr-fr/libr...v=vs.110).aspx

Alors la m�thode propre :
http://msdn.microsoft.com/fr-fr/libr...v=vs.110).aspx

he.... je dirais ni l'une ni l'autre (ou alors si a que eux deux la premi�re alors je crois), on a cr�e notre propre de socket et on utilise la librairie <winsock2.h>

Si vous ne pouvez pas vous servir de ce type, pourquoi ?

Si j'ai bien compris la question, je peut pas faire de thread abord car je suis d�j� sur une instruction bloquante (� mon avis)

[bacelar]

GAGNE!

Mon odorat de Troll ne me trahi jamais.

C'est clair qu'en utilisant une API datant de d�but des ann�es 80 (Unix BSD), le concept de traitement parall�le et de programmation �v�nementiel, c'est pas trop �a.

on a cr�e notre propre de socket et on utilise la librairie <winsock2.h>

Pourquoi ne pas faire une roue carr�e, les roues rondes des autres, c'est hasbeen. (sarcasme inside, on ne sait jamais )
Et c'est encore plus fun avec des pierres du pal�olithique, c'est plus dr�le. (...)

Bon, j'esp�re que vous vous n'�tes pas trop attach� � votre roue carr�e, vous prenez une pelle et allez l'enterrer au fond du jardin.

Remplacez ce vide affectif en utilisant la classe que j'ai donn�e dans mon dernier post http://msdn.microsoft.com/fr-fr/libr...v=vs.110).aspx.

L'autre lien, c'est une m�thode de cette classe, LOL.

P.S.: Vous nous cachez encore du code non manag� (qui date des ann�es 80 ou pas) ?

[invoceusse]

Oui ont y tien un peu ^^" vus que tout fonctionne, mais bon je vais passer chez le concessionnaire et essayer le nouveau mod�le.

P.S.: Vous nous cachez encore du code non manag� (qui date des ann�es 80 ou pas) ?

Bonne question...

[bacelar]

Oui ont y tien un peu ^^" vus que tout fonctionne

Comme votre super architecture.

je vais passer chez le concessionnaire et essayer le nouveau mod�le

Si vous voulez mais vous allez passer de la cothurne romaine � la navette spaciale, faudrait pensez � passer son brevet de pilote.

Si vous n'�tes pas foutu de savoir quelle partie de votre projet est en C++/CLI et quelle partie est en C++ Natif, vous �tes bon pour le crash.

[M�dinoc]

Ah, au passage: � quelle version du Framework .Net avez-vous droit? Parce que ReceiveAsync n'existe qu'� partir du Framework 3.5 (Visual Studio 2008).
Si vous �tes en 2.0, il faudra utiliser BeginReceive() � la place.