Date: Fri, 27 Jun 2003 18:42:28 -0400 From: Mike Makonnen <mtm@identd.net> To: deischen@freebsd.org Cc: marcel@xcllnt.net Subject: Re: libkse / libthr bugs? Message-ID: <20030627224228.SLIN12592.out001.verizon.net@kokeb.ambesa.net> In-Reply-To: <Pine.GSO.4.10.10306270650461.17094-100000@pcnet5.pcnet.com> References: <20030627063513.BRUI16647.out006.verizon.net@kokeb.ambesa.net> <Pine.GSO.4.10.10306270650461.17094-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 27 Jun 2003 07:14:43 -0400 (EDT)
Daniel Eischen <eischen@vigrid.com> wrote:
>
> To answer your first question, yes, I think it's necessary.
> Here's an example:
>
> void
> sigalarmhandler(int sig)
> {
> longjmp(env, 1);
> }
>
> int
> somenslookup(...)
> {
> ...
> alarm(5); /* Wait a maximum of 5 seconds. */
> if (setjmp(env) == 0) {
> nsdispatch(...);
> return (0);
> }
> return (-1);
> }
>
> Now perhaps this isn't the best example; imagine using
> something that used malloc()/free() or any one of the other
> locked libc functions. There is also the use of application
> level-locks which should work similarly, but by using libc
> example I avoid any argument about "the application shouldn't
> be doing that" :-)
If I understand correctly what you are saying is if the alarm fires before
somenslookup() returns successfully, the longjmp will make it return
unsuccessfully, and if it happened to be put on a queue in nsdispatch() it will
return to its caller still on the queue (which we clearly don't want).
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.
> It's also possible that the thread calls the same set
> of libc functions again, and if it isn't removed from
> the internal mutex queue, then you'd get the exact
> error message Marcel was seeing (already on mutexq).
I'm glad you brought this last point up because that has been on my mind as
well. Let's say an application is in one of the locked libc functions, receives
a signal and calls that same libc function from it's signal handler.
Furthermore, let's say that the thread had just aquired a lock in the libc
funtion before handling the signal. When this thread called the same libc
function from the signal handler and tried to aquire the same lock again, would
it not deadlock against itself?
So, the problem is not that the mutex/cond queues are special. It's that locking
from within libc in general is special, right?
I guess part of what has me confused is why the queues are being treated so
specially. I think the problem is one of general re-entrancy for library
functions designated async or thread safe. If so, then once I have a proper
handle on the issues I can start addressing them in libthr.
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?20030627224228.SLIN12592.out001.verizon.net>