From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 16:42:25 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 22BDD37B401; Fri, 27 Jun 2003 16:42:25 -0700 (PDT) Received: from out001.verizon.net (out001pub.verizon.net [206.46.170.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A1B643F93; Fri, 27 Jun 2003 16:42:24 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([141.156.32.244]) by out001.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030627234223.SVVN12592.out001.verizon.net@kokeb.ambesa.net>; Fri, 27 Jun 2003 18:42:23 -0500 Date: Fri, 27 Jun 2003 19:42:22 -0400 From: Mike Makonnen To: deischen@freebsd.org In-Reply-To: References: <20030627224228.SLIN12592.out001.verizon.net@kokeb.ambesa.net> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out001.verizon.net from [141.156.32.244] at Fri, 27 Jun 2003 18:42:23 -0500 Message-Id: <20030627234223.SVVN12592.out001.verizon.net@kokeb.ambesa.net> cc: freebsd-threads@freebsd.org cc: marcel@xcllnt.net Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 23:42:25 -0000 On Fri, 27 Jun 2003 19:10:25 -0400 (EDT) Daniel Eischen wrote: > > > How is this any different than holding some other resource? For example, if > > it had managed to aquire the lock before the longjmp from the signal > > handler? See below for what I mean. > > Libc mutexes and CVs use the single underscore version > so our threads library can tell the difference between > implementation locks and application locks. We should > be deferring signals while _holding_ one of these locks. > Mutexes in libc should be very short term, so deferring > signals while being held should be OK. But for CV's, > you could be on the CV queue for some time, and you > shouldn't be holding up signal delivery because of > that. > > My rule of thumb is to treat all locks the same and > don't keep threads on waiting queues of any sort while > running signal handlers. But once a lock is held, > that's a bit different because the application could > longjmp() out of the locked region and never release > the lock. We should probably defer signal delivery > while implementation mutexes, spinlocks, and low-level > locks are held. > Ok, thanks for all the input. I think I know what needs to be done now. 1. I'll change the stubs in libthr so that locking operations from within libc defer signals. 2. Fix the sigwrapper in libthr and introduce wrapper functions around signal(3) and sigaction(2) so that calls to signal handlers can be properly indirected through the sigwrapper function. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve