[linux-audio-dev] pthreads and signals

[Jack O'Quin]

Paul Davis <paul at linuxaudiosystems.com> writes:

> >  "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 suspect that the reason there's no good documentation on signal
interactions this is because the pthreads design sucks in that area.
The pthreads workgroup was never able to graft two such different
concepts as threads and UNIX signals together cleanly.  Maybe it can't
be done.

> i wonder if the kernel is enforcing the sync rule? i don't see how it
> could, though - it doesn't know about linuxthreads. 

I think it has to for POSIX compliance.

IIUC, the kernel sees each thread as a lightweight process.  It can
insist on either delivering the signal or terminating that
(lightweight) process.  I think that's what AIX did.

> 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.

That was true once, but no longer.  It dumps for me (with 2.4.19), but
maybe not always reliably for threads.

What may be confusing the issue is that lots of distributions
(including Debian) now eliminate all core dumps by set "ulimit -c" to
zero out of the box.  I'm explicitly setting "ulimit -c 100000".

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

Good idea.  

If you send me a patch or put it in CVS, I'll give it a try.
-- 
  Jack O'Quin
  Austin, Texas, USA