[linux-audio-dev] pthreads and signals

Paul Davis paul at linuxaudiosystems.com
Wed May 14 11:54:01 UTC 2003

>However, according to 'man signal', it seems to me that SIGSEGV (and 
>some others) *are* a bit special. I concluded that you have to make 

thats true. the deeper problem here is that every thread has blocked
SIGSEGV, except for the one that is waiting in sigwait. pthreads
semantics say that signal handlers are shared across threads, but that
masks are per-thread. hence, the thread that causes the segv should
*not* receive the signal - it should be delivered to the sigwait-ing

i looked at the source for linuxthreads, and i can only chalk this up
to another "error" in the implementation of linuxthreads. 

the only reason the handling ever appears to work is that most signals
are things like SIGINT/SIGTERM from a keyboard-input ctrl-c. this is
sent by the tty/term code to the entire process group, and thus even
the sigwait-ing thread gets it.

but any signal generated by a given thread within linuxthreads will be
delivered to that thread, regardless of what P.1003 says. hopefully,
NGPT will be better in this respect.

for now, i've fixed things so that things don't get so "odd" when a
segv happens - the handler exits the entire program regardless of the
thread it is executing in.


More information about the Linux-audio-dev mailing list