[linux-audio-dev] pthreads and signals

[Paul Davis]

>According to the O'Reilly] Pthreads (Caterpillar) book, signals due to
>system exceptions (like SIGFPE, or SIGSEGV) are "synchronous" and
>*must* be delivered to the offending thread.  Quoting...
>
>  "It will be that thread, in its own context, that will handle the
>  signal on behalf of the process as a whole."

thats a very useful thing to know. its not mentioned in the book i use
on threads (kleiman/shah/smaalders). they mention the sync/async
distinction, but not the requirement that they be handled by the
thread that caused them.

i wonder if the kernel is enforcing the sync rule? i don't see how it
could, though - it doesn't know about linuxthreads. we've blocked
SIGSEGV, yet the thread still receives it. strange. maybe you can't
block SIGSEGV? why wouldn't sigaction fail?

>I suspect something strange here.  I've seen crashes where the JACK
>thread has disappeared before the core dump was written.  Could they
>have been triggered by a segfault in the process() thread?  

unless the kernel has been fixed since i last checked on this (and i
have a vague memory that it has been), linux doesn't write core files
for multi-threaded processes.

>No, but I'm interested.  Right now, I'd be happy just to reliably get
>a dump with the backtrace stack of the offending thread intact.
>Sometimes that happens, other times not.

i'll try to fix JACK so that it does the same thing as ardour is doing
now (exiting from within the handler).

--p