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.