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

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

Marsh Posté le 14-05-2002 à 16:56:28    

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

Reply

Marsh Posté le 14-05-2002 à 16:56:28   

Reply

Marsh Posté le 14-05-2002 à 17:01:40    

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)
Reply

Marsh Posté le 14-05-2002 à 17:11:16    

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.

Reply

Marsh Posté le 14-05-2002 à 17:19:58    

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


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

Marsh Posté le 14-05-2002 à 17:44:39    

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

Reply

Marsh Posté le 14-05-2002 à 18:05:47    

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é !

Reply

Marsh Posté le 14-05-2002 à 22:03:38    

allez !  :bounce:

Reply

Marsh Posté le 15-05-2002 à 09:28:03    

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!!

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed