sigwait() brokeness (was Re: Threads regression tests)

[Daniel Eischen]

On Tue, 15 Jul 2003, David Schultz wrote:

> On Wed, Jul 16, 2003, David Xu wrote:
> > Can you test my libkse patch ?
> > http://people.freebsd.org/~davidxu/libpthread_bound.diffs
> > If you can test the patch to make sure I don't break signal
> > code, then I will commit this patch. 
> 
> Is there interest in incrementally building a threads-related
> regression test suite in src/tools/regression?  This would mean
> less breakage for people who are trying to use KSE/libthr, and an
> easy way for threads developers to be somewhat confident that
> their changes are correct.  For example, two weeks ago I was
> tearing my hair out over a sigwait() problem that caused the
> following program to deadlock.  Since I already bothered to
> isolate the bug, why not do the last 1% of the work and check in a
> test so that it never comes back?  Thoughts?

Yes, sigwait() appears to be broken in the kernel.
If the process is sigwait()ing on a signal set, and
one of those signals is pending or occurs, the
signal handler should not be invoked, especially
if the signal is masked.

The waitset is independent of the thread's signal
mask.  I think struct thread needs to grow a td_waitset
member.  If a signal arrives (or is already pending)
and it is present in the waitset, then the thread
should be woken up with the signal removed from the
pending set and no signal handler installed.

-- 
Dan Eischen