Newsgroup: it.comp.os.linux.development
Titolo: perché non muore del tutto?

continua l'epopea del programmone per l'esame.
Voglio che quando premo ctrl-C il programma scriva a video delle
informazioni e che poi tutti i suoi threda muoiano.
allora cattura SIGINT e scrivo la funzione.
In essa chiamo exit(0) e mediamente una volta su 3 non muore. Ho qualche
soluzione diversa dal prendere il pid del processo e farlo suicidare
tirandosi un SIGKILL ?

 tirandosi un SIGKILL ?
Hai ucciso i figli?
Bye.



il problema è che non so se il codice viene eseguito dal padre. Mi
spiego: l'handler del segnale è settano nel main, da cui di dipartono i
thread figli (thread, non task). Quindi i vari thread nuovi ereditano
l'handler e quindi questo verrà eseguito da uno solo a caso.
Nella documentazione dei pthread si dice che quando uno esce tutti
escono, e questo sembrerebbe esere vero facendo un po' di prove. Eppure
nel mio caso non è sempre così.
Attualemente ho adottato una soluzione bruta ma efficiente, quando la
routine fa tutto quello che deve fare in uscita alla fine invece che
chiamare exit si lancia su di essa un sigkill....

 ereditano l'handler e quindi questo verrà eseguito da uno solo a caso.
non e` che hai una select() o una poll() in attesa ?
in ogni caso, guardati sigwait() e pthread_sigmask(), per un mio sw
multithread ho implementato la gestione dei segnali mediante un thread
separato che esegue la sigwait() e poi uno switch, una rozza signal
queue insomma.
se sei interessato a vedere come ho fatto (uso la glib cmq) guardati
threads.c da 
http://sf.net/projects/suxserv
 [cvs]
hope this helps :)
vjt
-- 
pub 1024D/F04476A2 :: 6807 EEA5 7F97 AC9A D8EF  AE73 64CD 71A2 F044 76A2
http://suxserv.sourceforge.net/vjt.asc
        ||  This signature has
Free advertisement: 
http://www.freebsd.org/
   ||      Super Cow Powers.

On Wed, 19 Feb 2003 12:21:34 +0100, Ottavio Campana 
was talkin'about:
#define IMHO

Puoi imposhare il sighandler nel padre prima di spawnare i thread. Cosi'
dovrebbero ereditare la sigmask e pure il callback e basterebbe un SIGINT a
qualsiasi dei thread per fermare tutto. Pero' in generale la gestione dei
segnali asincroni con i thread e' una brutta bestia. Una buona soluzione e'
di solito un serializzatore a semafori.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
-<! Computer programmers never die, they just raise an unhandled exception.!>-

 buona soluzione e' di solito un serializzatore a semafori.
??? cioè?

 un SIGINT a qualsiasi dei thread per fermare tutto. Pero' in generale
Aspetta, ricordo male o in questo caso il segnale viene ricevuto da solo
uno, e uno qualsiasi, dei processi con cui vengono realizzati i thread?
Cio' spiegherebbe lo strano comportamento...
-- 
HappyCactus - Linux User #209744 - 
http://pngstego.sourceforge.net
 
              pngstego 0.3.2 has been released! 
/* Ci sono 10 categorie di persone al mondo: quelle che capiscono */
/* il sistema binario e quelle che non lo capiscono.              */

 ??? cioè?
Un thread dedicato che blocchi i segnali e li metta in una coda, ogni volta
alzando un semaforo. La gestione viene poi fatta da un altro thread che
aspetta il semaforo e fa il pop della lifo. Piu' o meno, non e' cosi'
lineare, ma se ci pensi su e fai un paio di simulazioni puoi ricostruire
tutto il locking necessario.
Questo deriva dal fatto che l'unico costrutto di sincronizzazione
async-signal-safe e' il semaforo.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! Battles Are Fought By Those With The Courage To Believe !>-
  		Manowar - Courage

 async-signal-safe e' il semaforo.
avevo fatto un giochino del genere con un paio di costrutti c++, che 
generavano e gestivano messaggi tramite Observer e Command, ne avevo 
anche provato un paio di simulazioni MultiThread senza problemi. Se 
Ottavio pensa di darci un'occhiata e' sul mio sito alla sezione Dev:
http://web.tiscali.it/blakwolf/dev.htm
Un avviso: ho una visione pseudo artistica dell'implementazione dei 
pattern in c++ :)
-- 
#include <stdio.h>/* (C) BW2K+3 This code is released under GPL 2+ */
int main(){char c[]={98,108,97,99,107,119,111,108,102,64,100,101,115,112,
97,109,109,101,100,46,99,111,109,32,119,101,98,46,116,105,115,99,97,108,
105,46,105,116,47,98,108,97,107,119,111,108,102,0};printf("%s\n",c);}

 Cio' spiegherebbe lo strano comportamento...
Beh, lo mandi a chi vuoi ed e' quello che lo riceve. Puo' esserci una sola
routine di gestione per tutti i thread ma la sigmask e' arbitraria.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! *Real* programmers use cat > a.out! No way, /real/ ones
        use zcat > a.out 'cause you can type faster that way. !>-
                -- from a Slashdot discussion

 threads.c da 
http://sf.net/projects/suxserv
 [cvs]
che voi sappiate killall ha qualche funzionamento particolare? No, perché
se lanci i segnali con una system che chiama killall tutto va da dio....