libkse / libthr bugs?

[Mike Makonnen]

On Fri, 27 Jun 2003 00:26:33 -0400 (EDT)
Daniel Eischen <eischen at vigrid.com> wrote:

> 
> Signal handling and locks (low-level, CV, mutex, etc) are
> somewhat difficult to deal with, especially when there are
> mutexes in libc that the application doesn't even see.
> 

Heh. no kidding :-)

> In general, signals can't be deferred around big locks
> (mutexes, CVs, rwlocks, etc), but may be around low-level
> locks (which is what I think your patch is doing).

Correct. It wasn't designed to solve Marcel's problem. It was to narrow the
possible culprits down.

> It is valid for an application to have a thread blocked
> in pthread_mutex_lock(), pthread_cond_timedwait(), etc,
> receive a signal.  The signal handler should run, but
> those functions should not return EINTR; they should
> continue blocking when the handler returns.
>
> It is also valid for a thread to be blocked in fwrite()
> (or some other libc function that has locking) and
> receive a signal.

Yes, this is my understanding as well-- unless they attempt to use a pthreads
facility or call non-async safe libc routines from signal handlers, in which
case all bets are off. I believe the pthread_cancel() family of functions is the
only one that's guaranteed to be async safe.


> In either case, you also have to handle the the thread
> _not_ returning normally; it could [sig]longjmp() or
> setcontext() out of the locked area.  So if you are keeping
> any internal queues for mutexes, CVs, etc, you have
> to ensure the thread is removed from the queue before
> the signal handler is invoked, and then reinsert the
> thread back into the queue if the signal handler
> returns normally.

This is what I don't understand very well. Is it necessary in a 1:1 library? I
can understand this sort of behind-the-scenes manipultaion in lic_r or libkse,
where the uts might need to be protected from those kinds of situations. But for
libthr, where all scheduling and signaling is taken care of in the kernel I
would be inclined to say "all bets are off." As I wrote earlier, it's my
understanding that the only pthreads routines you can rely on to be async safe
are pthread_cancel() and friends.

I admit I could be grossly misunderstanding the situation, in which case I
would really appreciate a clarification.

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