From owner-freebsd-threads@FreeBSD.ORG Wed Jul 16 12:16:52 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CE1537B401; Wed, 16 Jul 2003 12:16:52 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C28EA43F85; Wed, 16 Jul 2003 12:16:51 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h6GJFoAI024690; Wed, 16 Jul 2003 15:15:50 -0400 (EDT) Date: Wed, 16 Jul 2003 15:15:50 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: David Schultz In-Reply-To: <20030716055247.GA39968@HAL9000.homeunix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Craig Rodrigues cc: David Xu cc: freebsd-threads@freebsd.org Subject: sigwait() brokeness (was Re: Threads regression tests) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2003 19:16:52 -0000 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