C++

[MFC] Terminer un thread à la barbare mais proprement quand même ???

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : [MFC] Terminer un thread à la barbare mais proprement quand même ???

torpe23

Je dois discuter avec une carte d'acquisition dans le PC, mais parfois ça bloque. J'utilise donc un thread qui se charge de faire ça, pour que si ça bloque, l'appli ne soit pas plantée complètement.
Pour l'instant, je comptais utiliser la fcn "TerminateThread()" qui arrête le thread quoiqu'il arrive : le problème, je crois, c'est que cette fonction n'est pas super propre et je risque d'avoir des fuites de mémoires ou des écrasements de dll (dixit la mdsn)...
Alors comment faire pour quitter ma thread bloqué par une commande d'E/S, sans tout bousiller ???

Merci d'avance et bonne fin d'aprèm !

Joel

Publicité

Harkonnen

Modérateur
Un modo pour les bannir tous

Citation :

The best approach to terminate threads gracefully is either to use a wait condition which includes extra wait events that can always be satisfied by a controlling thread, or to use alertable waits:
Sleep calls :

Replace Sleep function calls with a WaitForSingleObject function with a controlling object (probably an event) specified as the object to wait for and the sleep time as the timeout. The controlling thread ends the sleep early by signaling the controlling object. This would indicate to the thread that something needs to be done (cleanup).

WaitForSingleObject :

Replace the single object wait to a wait for two objects--the original object and an extra object (probably an event) that can control ending the wait. The WaitForMultipleObjects function would be used, specifying FALSE for fWaitAll, which would allow a controlling thread to set to event to end the wait. The thread code would detect that this event was signaled and would know that it needs to clean up.

WaitForMultipleObjects :

This is straight forward if the wait was for any single object to become signaled (fWaitAll was FALSE). Just add the control event as in the case of the single-object wait. For a multiple-object wait, there is no easy answer because the WaitForMultipleObjects function cannot be asked to wait for one set of objects to become signaled or another.

Jeffrey Richter wrote a column in Microsoft Systems Journal (January, 1997) that discusses an approach of using alertable waits to create an API that allows you to accomplish this.

It might be easier to use alertable waits in that you do not need to add an event. This method also affords extra flexibility in that any extra work can be queued up for the waiting thread. To use this method, use the alertable version of the synchronization functions ( WaitForSingleObjectEx , WaitForMultipleObjectsEx , MsgWaitForMultipleObjectsEx , SignalObjectAndWait , SleepEx ), and specify that the thread is alertable (bAltertable set to TRUE). The controlling thread now can specify that the thread should perform cleanup by queuing a user-mode APC by using the QueueUserAPC function.

http://support.microsoft.com/defau [...] US;q254956

---------------
J'ai un string dans l'array (Paris Hilton)

torpe23

Ouais, mais j'avais déja vu tout ça !
Avec ces trucs là, tu peux arrêter ton thread prématurément mais il faut qu'il tourne encore pour choper des messages. Moi, mon thread, s'il est bloqué, il est bloqué (!) et il ne peut plus recevoir de message, ni continuer ! Il est bloqué sur la fonction qui discute avec la carte et on ne peut rien faire (sauf TerminateThread() )...
enfin, si justement, je me renseigne pour savoir s'il n'y a pas un moyen autre que d'appeler cette fonction.

Harkonnen

Modérateur
Un modo pour les bannir tous

Et un ExitThread(), ce n'est pas envisageable ?

---------------
J'ai un string dans l'array (Paris Hilton)

try58

Comment tu t'y prend pour faire dialoguer ton process et la carte d'aquisition ?

torpe23

D'après ce que je vois dans la mdsn, exitthread doit être appeler par le thread lui même : ce qui n'est pas possible dans mon cas, si le thread est bloqué !

Pour le dialogue avec la carte, je ne sais pas car ce n'est pas moi qui m'occupe de ça : mais dis-moi, si tu as des idées sur ça pour que j'en discute avec le concerné !

torpe23

allez ! :bounce:

try58

Moi je pensais creer un thread de debug avec la fct DebugActiveProcess:

The DebugActiveProcess function allows a debugger to attach to an active process and then debug it. To stop debugging the process, you must exit the process. Exiting the debugger will also exit the process.

BOOL DebugActiveProcess(
DWORD dwProcessId // process to be debugged
);

Ensuite utiliser une boucle infinie qui va detecter tous les evenements en utilisant la fct WaitForDebugEvent:

The WaitForDebugEvent function waits for a debugging event to occur in a process being debugged.

BOOL WaitForDebugEvent(
LPDEBUG_EVENT lpDebugEvent, // debug event information
DWORD dwMilliseconds // time-out value
);

Deja ca te permettrai de voir sur quel evenement ton process se bloque. Normalement, quand tu fais un ExitProcess sur le Process de debug, il doit egalement terminer le process debugge. Par contre je ne sais pas si il le fait proprement!!

FORUM HardWare.fr

Programmation

C++

[MFC] Terminer un thread à la barbare mais proprement quand même ???

Sujets relatifs
[MFC] Etiquette de renseignements jaune ???	Mais ou est passé le thread ?
[ THREAD ] pthread_join et pthread_exit : type du paramètre de sortie?	MFC - Comment CDialog fonctionne !?!
[ JAVA ] encore le gros bleu !! thread thread thread ?!?!	[MFC] Forcer une taille de fenêtre
[JAVA] Thread => occupation processeur	[ Delphi ] thread... ? :)
[ THREAD ] A ceux qui savent programmer les threads sous Linux/Unix	[MFC] Edit control + informations par ligne
Plus de sujets relatifs à : [MFC] Terminer un thread à la barbare mais proprement quand même ???

Page générée en 0.054 secondes