Date: Fri, 27 Jun 2003 19:42:22 -0400 From: Mike Makonnen <mtm@identd.net> To: deischen@freebsd.org Cc: marcel@xcllnt.net Subject: Re: libkse / libthr bugs? Message-ID: <20030627234223.SVVN12592.out001.verizon.net@kokeb.ambesa.net> In-Reply-To: <Pine.GSO.4.10.10306271845300.14664-100000@pcnet5.pcnet.com> References: <20030627224228.SLIN12592.out001.verizon.net@kokeb.ambesa.net> <Pine.GSO.4.10.10306271845300.14664-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 27 Jun 2003 19:10:25 -0400 (EDT) Daniel Eischen <eischen@vigrid.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030627234223.SVVN12592.out001.verizon.net>