Gestione del segnale in pthreads

Question

Ho creato un pthread e installato un gestore di segnale al suo interno, proprio come facciamo nella funzione main(). Il gestore di segnale del thread è una funzione separata. Sorprendentemente, non funziona, cioè il gestore del segnale del thread non è in grado di rilevare i segnali.

Ecco il codice:

#include <pthread.h> 
#include <unistd.h> 
#include <sys/types.h> 
#include <stdio.h> 
#include <signal.h> 

typedef struct data 
{ 
char name[10]; 
int age; 
}data; 

void sig_func(int sig) 
{ 
printf("Caught signal: %d\n",sig); 
signal(SIGSEGV,sig_func); 
} 

void func(data *p) 
{ 
printf("This is from thread function\n"); 
signal(SIGSEGV,sig_func); // Register signal handler inside thread 
strcpy(p->name,"Mr. Linux"); 
p->age=30; 
sleep(2); // Sleep to catch the signal 
} 

int main() 
{ 
pthread_t tid; 
pthread_attr_t attr; 
data *ptr; 

pthread_attr_init(&attr); 
pthread_create(&tid,&attr,(void*)func,ptr); 
pthread_kill(tid,SIGSEGV); 

pthread_join(tid,NULL); 
printf("Name:%s\n",ptr->name); 
printf("Age:%d\n",ptr->age); 
} 

uscita:

Segmentation fault (che significa che il segnale non è catturato dal gestore)

Answer 1

Ci sono diversi problemi con il tuo codice:

• ptr non è inizializzata, in modo che tutti i ptr-> parti saranno in crash il programma
• si sta chiamando pthread_kill() immediatamente, molto probabile prima che il gestore di segnale sia stato installato, e in una discussione (che ha un comportamento non specificato)
• chiami printf() da un gestore di segnale, che non è garantito per funzionare (vedi man 7 signal per un elenco di funzioni sicure)

Questo funziona molto meglio, anche se si sarebbe ancora bisogno di una corretta sincronizzazione dei thread, e come detto altrove, è necessario utilizzare sigaction():

#include <pthread.h> 
#include <unistd.h> 
#include <sys/types.h> 
#include <stdio.h> 
#include <signal.h> 

typedef struct data 
{ 
char name[10]; 
int age; 
}data; 

void sig_func(int sig) 
{ 
write(1, "Caught signal 11\n", 17); 
signal(SIGSEGV,sig_func); 
} 

void func(data *p) 
{ 
fprintf(stderr, "This is from thread function\n"); 
strcpy(p->name,"Mr. Linux"); 
p->age=30; 
sleep(2); // Sleep to catch the signal 
} 

int main() 
{ 
pthread_t tid; 
pthread_attr_t attr; 
data d; 
data *ptr = &d; 

signal(SIGSEGV,sig_func); // Register signal handler before going multithread 
pthread_attr_init(&attr); 
pthread_create(&tid,&attr,(void*)func,ptr); 
sleep(1); // Leave time for initialisation 
pthread_kill(tid,SIGSEGV); 

pthread_join(tid,NULL); 
fprintf(stderr, "Name:%s\n",ptr->name); 
fprintf(stderr, "Age:%d\n",ptr->age); 
} 

Edit: installare sighandler nel thread principale

Answer 2

ritengo il nucleo del problema è che i segnali vengono inviati al processo nel suo complesso, piuttosto che ai singoli thread. Comunemente, un singolo thread è nominato per gestire tutti i segnali; tutti gli altri thread (incluso il thread principale) devono essere block the signals using pthread_sigmask().

È possibile impostare la maschera per bloccare tutti i segnali, avviare il filo del gestore di segnale, smascherare i segnali che si desidera gestire e quindi tornare indietro nel thread principale, avviare tutti gli altri thread necessari. Essi erediteranno la maschera "blocca tutti i segnali" dal thread principale.

Per inciso, è ora di allontanarsi da signal(3) e passare a sigaction(2), che ha semantica affidabile ed è meglio standardizzata. (E quindi più portabile.)

Answer 3

L'unico problema con il codice che nessuno ha ancora menzionato è che, mentre il blocco del segnale (e la consegna, se si utilizza pthread_kill o raise) sono per-thread, i gestori di segnale sono per processo. Ciò significa che sono un pessimo meccanismo per la comunicazione tra thread, soprattutto se il codice verrà mai utilizzato come codice di libreria, dal momento che è un comportamento estremamente negativo per una libreria modificare i gestori di segnale del chiamante.

Si noti inoltre che l'utilizzo di gestori di segnale per la comunicazione tra thread ha prestazioni non ottimali rispetto ad altri metodi di segnalazione di thread come variabili di condizione o barriere, poiché c'è almeno una transizione utente-utente-utente aggiuntiva (quando il gestore di segnale restituisce).