Paul Davis <paul(a)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