Newsgroup: it.comp.programmare.win32
Titolo: Conoscere lo stato di un Thread

Come da oggetto!
Ho un CWinThread puntato da pThread
Ora durante l'esecuzione del Thread chiamo la AFxEndThread(0)
ma il puntatore rimane valido, ma i membri no (perchč AfxEndThread ha
cancellato il Thread)
ora se verifico il puntatore pThread nn vado bene perchč č diverso da NULL
C'č una funzione che mi testa i membri, o se il Thread č in esecuzione?
Grazie
JoGiň

> C'è una funzione che mi testa i membri, o se il Thread è in esecuzione?
Vuoi sapere se il thread è uscito con AFxEndThread(0) ?
Guarda se il pThread è segnalato con la WaitForObject().
CWinThread *pWinThread;
[..]
 WaitForSingleObject( pWinThread->m_hThread, INFINITE) ;
Ciao !!

Giacomo ha scritto:



non va bene, perchè dovrebbe accedere al membro m_hThread dell'oggetto,
che non è + valido; aldilà del discorso sui threads, in generale, per
sapere se un puntatore punta ad un valido blocco del free store, esiste in
Visual C++ la funzione _CrtIsValidHeapPointer, solo che non sono sicuro
che vada bene anche per la modalità release (anzi non credo).
ciao.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 che non č + valido;
Sě č vero, precisiamo meglio. Dall'MSDN secondo Microsoft:
When a CWinThread thread terminates, the thread object is deleted. This
means you cannot access the m_hThread data member because the CWinThread
object no longer exists. To avoid this situation, do one of the following
two things:
Set the m_bAutoDelete data member to FALSE. This allows the CWinThread
object to survive after the thread has been terminated. You can then access
the m_hThread data member after the thread has been terminated. If you use
this technique, however, you are responsible for destroying the CWinThread
object as the framework will not automatically delete it for you. This is
the preferred method.
-or-
Store the thread's handle separately. After the thread is created, copy its
m_hThread data member (using ::DuplicateHandle) to another variable and
access it through that variable. This way the object is deleted
automatically upon termination and you can still find out why the thread
terminated. Be careful that the thread does not terminate before you can
duplicate the handle. The safest way to do this is to pass CREATE_SUSPENDED
to AfxBeginThread, store the handle, and then resume the thread by calling
ResumeThread.
Giacomo

 Sì è vero, precisiamo meglio. Dall'MSDN secondo Microsoft:


 mi sembra + una patch.
Mi sembrano affermazione eretiche, io ormai ho passato l'età per ribellarmi
al sistema (operativo). Come vedi copio ed incollo l'MSDN.
Le patch del sistema operativo adesso si chiamano "service-pack" ;-)
Attento a come quoti, ai ripetuto tutto il mio lunghissimo post, adesso i
byte in rete sono gratis, ma è considerato ancora cattiva educazione e rende
difficile seguire un thread (di news).
Ciao !!!

 Ora c'è un evento, un qualcosa che mi dice che il thread è terminato?
no. In Win32 non ci sono i segnali
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.3. C, C++ and ASM developers
                               and beta testers are welcome!

 no. In Win32 non ci sono i segnali
"Fortunatamente", aggiungerei. :)
A proposito, sto leggendo con grande euforia questo libro che ormai
appartiene alla storia:
http://www.simson.net/ref/ugh.pdf
-- 
Lorenzo


http://www.simson.net/ref/ugh.pdf
...e che riporta, nell'appendice B, la piů grande barzelletta del
secolo ;-)

 "Fortunatamente", aggiungerei. :)
scherzi? è l'unico modo per ricevere eventi asincroni


 secolo ;-)
...o forse no? :)
-- 
Lorenzo

 scherzi? è l'unico modo per ricevere eventi asincroni
Per perderli, vorrai dire... :)
-- 
Lorenzo

 ....o forse no? :)
Basta cercare in rete per "Creators admit UNIX, C hoax" per accorgersi che
č un "joke" che va in giro in rete da molto tempo.


 Per perderli, vorrai dire... :)
vediamo... uhm... no, non credo di capire. Esplicitare, prego


 prego
Suppongo quindi che non te ne siano mai arrivati due quasi
contemporaneamente. In Unix (o perlomeno in Linux, l'unico in cui ho
provato) i segnali non hanno una coda, e di fatto sono utili solo per
segnalare un evento sporadico e/o non ripetitivo.
-- 
Lorenzo

 è un "joke" che va in giro in rete da molto tempo.
Ma si`, e` chiaro che e` un joke, ovviamente ero sarcastico! Ritchie ha
persino scritto una anti-foreword per quel libro, che definire
"caustica" e` dire poco...
-- 
Lorenzo

 ripetitivo.
non parlavo dell'implementazione UNIX dei segnali, ma del concetto, che 
in Windows è completamente assente, e di cui si sente la mancanza


 mancanza
Quale differenza effettiva c'e` fra un signal()/wait() e un
SetEvent()/WaitForSingleObject() ?
-- 
Lorenzo