14 May
2003
14 May
'03
1:48 p.m.
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
thread.
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.
--p