From owner-freebsd-threads@FreeBSD.ORG Wed Sep 22 00:45:55 2004 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 267CD16A4CE; Wed, 22 Sep 2004 00:45:55 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA18243D5A; Wed, 22 Sep 2004 00:45:54 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) i8M0jpKi007725; Tue, 21 Sep 2004 20:45:51 -0400 (EDT) Date: Tue, 21 Sep 2004 20:45:51 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <4150C95E.4030407@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: davidxu@freebsd.org cc: threads@freebsd.org Subject: Re: SIGILL @ pthread_create() after execv X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2004 00:45:55 -0000 On Tue, 21 Sep 2004, Julian Elischer wrote: > > > Daniel Eischen wrote: > > >This looks OK to me. > > > > > > Ok, so what happens if 2 threads call execve() at the same time and the > first one in fails > but the second one would succeed? > By the time we've discovered that the first would have failed, we've > probably already > told the second that it was too late. Well, we can easily stop that in userland by taking a mutex or lock before the exec() then releasing it if the exec fails. Both libthr and libpthread would have to do this, I think. > In this case teh second thread has 2 options > (assuming 2 processors) > 1/ on dicovering that P_INEXEC is already set, it could just die, (i.e > release locks it has and call thread_exit(). > 2/ it could sleep on something, knowing that the leading thread will > wake it up and force it to > return (and thus call thread_exit() in userret) when it eventually calls > thread_single() > after it has passed all the permissions tests. Probably #2, but you could just disregard this situation if you want to put the onus on userland. I think an msleep() or CV would work if you want to block in the kernel. If the exec fails(), you can just wakeup() any waiters. -- Dan Eischen