libkse / libthr bugs?

[Mike Makonnen]

On Fri, 27 Jun 2003 19:10:25 -0400 (EDT)
Daniel Eischen <eischen at 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 at identd.net | D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9
mtm at FreeBSD.Org| FreeBSD - The Power To Serve