From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 15:42:30 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 B24BE37B401; Fri, 27 Jun 2003 15:42:30 -0700 (PDT) Received: from out001.verizon.net (out001pub.verizon.net [206.46.170.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id C566943FDD; Fri, 27 Jun 2003 15:42:29 -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 <20030627224228.SLIN12592.out001.verizon.net@kokeb.ambesa.net>; Fri, 27 Jun 2003 17:42:28 -0500 Date: Fri, 27 Jun 2003 18:42:28 -0400 From: Mike Makonnen To: deischen@freebsd.org In-Reply-To: References: <20030627063513.BRUI16647.out006.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 17:42:28 -0500 Message-Id: <20030627224228.SLIN12592.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 22:42:31 -0000 On Fri, 27 Jun 2003 07:14:43 -0400 (EDT) Daniel Eischen 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