Date: Wed, 16 Jul 2003 15:15:50 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: David Schultz <das@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: sigwait() brokeness (was Re: Threads regression tests) Message-ID: <Pine.GSO.4.10.10307161502040.22236-100000@pcnet5.pcnet.com> In-Reply-To: <20030716055247.GA39968@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10307161502040.22236-100000>