CwinThread et OnIdle

Bonjour,

J'ai deux soucis :

1- J'ai une DLL qui lance un thread via :
m_pClientThread = (CClientThread*)AfxBeginThread(RUNTIME_CLASS(CClientThread), THREAD_PRIORITY_NORMAL, 0, CREATE_SUSPENDED);

Ce thread a pour but de recevoir des données sur un socket et de mettre a jour une structure de portée globale.

Ca marche bien mais à la fermeture du programme, je veux tuer proprement le thread. Je lui envoie donc un message via:
::PostThreadMessage(m_pClientThread->m_nThreadID, WM_TERM_THREAD, 0, 0)

ou m_pClientThread est le pointeur sur le thread et WM_TERM_THREAD un message utilisateur pour signaler au thread qu'il doit se terminer.

Dans le thread, j'ai un mapping :

BEGIN_MESSAGE_MAP(CClientThread, CWinThread)
//{{AFX_MSG_MAP(CClientThread)
// NOTE - the ClassWizard will add and remove mapping macros here.
//}}AFX_MSG_MAP
ON_THREAD_MESSAGE(WM_TERM_THREAD, OnTermThread)
END_MESSAGE_MAP()

pourtant, la fonction OnTermThread n'est jamais appelée !
En fait, ::PostThreadMessage me retourne 0 (echec).

2 - J'ai voulu utiliser la fonction membre (surchargée) OnIdle de ma classe de thread pour mettre ma structure a jour régulièrement, mais elle n'est appelée qu'une à deux fois au démarrage de l'appli. et plus du tout ensuite ...

???
Pour moi c'est assez mystérieux, et j'ai rien trouvé de concluant sur MSDN et internet.
Une idée ??

Olivier

Ton thread possède-t-il une boucle de messages ?
Si c'est un thread de travail (worker thread), il n'en possède pas et ne risquera donc pas de recevoir des messages...

Salut Médinoc!

Merci de ton aide,

Oui, mon thread possède à priori une boucle de messages, c'est un thread d'interface MFC.
J'ai tout de même essayé de mettre :

PeekMessage( &msg, NULL, 0, 0, PM_NOREMOVE );

pour forcer la création de la boucle dans le constructeur de ma classe de thread, sans résultat.

Pour ma question concernant OnIdle, c'est résolu : j'avais laissé le paramètre lCount à 0, donc le système d'exploitation ne donnait plus de temps de traitement à OnIdle. en fixan lCount à une valeur non nulle c'est résolu ...

Ca veux dire quoi précisémment "à la fermeture du programme".

Si vous attendez trop longtemps, la fenêtre du thread n'existe peut-être plus.

Pour continuer avec la fixette sur le découplage exécutable-dll, je vous conseil de d'utiliser une fonction "UnInit" qui serait appelé avant le déchargement de la dll (comme une méthode Init au chargement de la dll).
Vous devez avoir un mécanisme synchrone de fin de programme (PostMessage est un mécanisme éminemment asynchrone) pour arrêter correctement votre programme.

hein ?

mmm excuse moi bacelar, tu ne te serais pas trompé de message en répondant, je ne vois pas le rapport

;-)

Olivier

Non.
Les destructeurs des globales, c'est bien trop tard pour faire le ménage dans les threads car il y déjà eu le déchargement de bon nombres de dll.

Il faut appeler une fonction de la dll comme "UnInit" par exemple, avant la fin du programme et cette fonction ne rendra la main uniquement quand les threads créés par la dll seront terminés. C'est le seul moyen propre de faire les choses.
Sinon, vous aller avoir des problèmes de thread tués violemment avec risque d'incohérence de données ou des deadlocks lors du déchargement des dll en fin d'exécution.

Oups pardon,

Je comprends maintenant, merci pour la clarification.
En fait, ma DLL est une DLL d'interface, avec une classe dérivée de CWinApp.
J'ai ajouté une surcharge de ExitInstance qui doit tuer le thread secondaire créé par la DLL.
Lors de la fermeture de l'appli principale, le ExitInstance de la DLL est bien appelé, et c'est lui qui envoie le message via PostThreadMessage au thread secondaire pour lui demander de se terminer.

A la fermeture de l'appli principale, je constate bien un appel à ExitInstance de ma classe dérivée de CWinApp dans la DLL. Cependant l'appel à PostThreadMessage retourne 0 et le thread n'est pas tué proprement, car je constate des fuites mémoires correspondant à des variable du thread. De plus, un point d'arrêt dans la fonction CClientThread::OnTermThread, qui est censée être appelée pour faire le ménage, n'est jamais atteint ce qui me fait dire que le message de terminaison envoyé par PostThreadMessage n'est pas reçu.

En quelque sorte, il me semble que mon ExitInstance de la DLL correspond au UnInit que tu recommande...

Où est-ce que je fait faux ?

Olivier

C'est clair, ExitInstance correspond pile poil à mon "UnInit".
Comme quoi, les concepteurs des MFC ont pensés à (presque) tous.

J'ai signalé aussi que mon "UnInit", devenu ExitInstance, doit être synchrone.
Je veux dire par là qu'ExitInstance ne devrait faire un return qu'après la fin des threads de la dll.
Il faut donc faire une attente sur la fin du ou des threads de la dll.
Un WaitForSingleObjet ou un WaitForMultipleObjects sur le ou les handles du ou des threads de la dll permettrait d'attendre de manière synchrone mais passive la fin du ou des threads de la dll.

Un PostMessage est totalement asynchrone, contrairement à un SendMessage. Après un PostMessage, la seule certitude est que le message soit présent dans la file de message du thread créateur de la fenêtre correspondant au handle de l'appel, c'est tous.

Il faut attendre la fin de l'exécution du ou des threads et la manière la plus sûr est d'attendre que le ou les handles du ou des threads soi(en)t "signalé". L'OS s'occupe de faire ce travail lui même.

Salut Bacelar,

merci encore pour ton aide.
J'ai un peu creusé dans la direction indiquée et j'ai finalement compris pourquoi les messages n'arrivait pas à destination :

Mon programme est une DLL, qui crée un thread chargé des communications avec un serveur pour mettre à jour une structure. Le thread de com n'est pas tué proprement, car il est tué trop vite...

Dans mes test, j'appelle ma DLL depuis une application MFC constituée d'une boite de dialogue modale. à la fermeture de la boite de dialogue, le ExitInstance de ma DLL est bien appelé, mais il ne sert à rien que lui essaye de tuer proprement le thread de communication, QUI EST DEJA MORT !
Il semble que le thread est tué dès que la boite de dialogue rends la main, donc le PostThreadMessage censé demander au thread de se terminer proprement retourne 0 !
Je ne comprends pas bien pourquoi le thread se termine sans que j'ai le moindre controle dessus ...
une idée ?

Etes-vous sur que le thread est déjà mort au moment de l'ExitInstance de la dll?
Utilisez l'handle du thread pour vérifier que le thread est bien mort, il doit déjà être "signalé" s'il est déjà mort.

Si c'est vraiment le cas, il suffit d'appeler une fonction "UnInit" de la dll que vous avez précédemment implémenté dans la dll pour faire le ménage. Cet appel à "UnInit" se fera au moment de la destruction de la fenêtre principale.

Attention, PostMessage n'est pas synchrone, vous devez, dans fonction "UnInit", attendre la fin du thread avec un WaitForSingleObject.

Si vous utilisez les primitives MFC pour créer des threads d'interfaces, il y a fort à parier que les MFC maintiennent une structure avec l'ensemble des threads "MFC" créés et s'en servent lors de la terminaison du programme.

Citation:

---

Envoyé par oliver_mpt

hein ?

mmm excuse moi bacelar, tu ne te serais pas trompé de message en répondant, je ne vois pas le rapport
Olivier

---

1-Y'a un forum MFC
2-eh ou Bacelar a raison comment charges-tu et décharges-tu la dll ?
Est-ce que tu appelles bien WaitForSingleObject() ?
Si tu fais FreeLibrary() quelque part il faut terminer l'exécution du Thread.
Perso je n'aime pas les BEGIN_MESSAGE_MAP /ON_ avec les macros et cette méthode de "mapping" , je préfère appeler CWnd :: PreTranslateMessage qui gère les messages comme dans un programme basique win32.
Si la dll ne contient pas de controles genre PushButton je préferrais une dll win32 pure plutot qu'avec MFC..
MFC c'est bien pour faire des applis fenêtrées UI mais pas trop pour le système