Subject: Re: sigwait(2) implementation
To: Jason R Thorpe <thorpej@wasabisystems.com>
From: Jaromir Dolecek <jdolecek@netbsd.org>
List: tech-kern
Date: 01/28/2003 21:37:50
I've finished the kernel, single-thread version and have the pthread
version mostly working too - for some cases at least.

Now, I have slight problem with how signals are delivered to
userland in SA case.

If the signal is blocked at process level, libpthread won't receive
even an upcall when the signal is posted. I guess the upcall
would be eventually generated when the signal would be unblocked
on process level. Also, when the signal is left to use default
action (say SIGUSR1, terminate process), the process would be
terminated by kernel without chance to intercept the signal delivery.

Both of these make purely userland sig*wait() a bit difficult.

The first can be overcame by setting thread signal mask to allow
delivery of the signals. This costs a syscall (the process mask
has to be adjusted), but would make it work.  However, the second
one can only be overcame by installing actual do-nothing signal
handlers, and intercepting the signal upcall.

I think of three possible solutions.

One would be to make one of the threads blocked in sig*wait() to
call actual syscall sigtimedwait(), with sum of all the signal sets
various threads wait for. Another option would be to have kernel
send upcalls about _all_ signals, even blocked ones or ones with
SIG_DFL, to SA  application. libpthread would then intercept the
delivery and route signals to sigwaiters appropriately.  Third
option would be to install dummy signal handlers on SA startup
(from pthread__signal_init()). This would in effect be same as #2
(unblock all signals, replace SIG_DFL with dummy handler), but
without kernel tweaks.

Neither of there is very good. The first one uses a syscall and
requires synchronization (not too much, there is normally single
thread sigwaiting). The latter two lose proper default signal
handling for stuff like SIGFPU/SIGXCPU etc.

All in all, it seems the first one is the one most likely
to work properly. It sucks that it requires a syscall, tho.
But it may still be cheaper than upcall for every signal
on the end.

Any better idea?

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-