From owner-freebsd-threads@FreeBSD.ORG Wed Sep 22 00:37:51 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 1B89616A4CE; Wed, 22 Sep 2004 00:37:51 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4D4F43D31; Wed, 22 Sep 2004 00:37:50 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 907E47A41E; Tue, 21 Sep 2004 17:37:50 -0700 (PDT) Message-ID: <4150C95E.4030407@elischer.org> Date: Tue, 21 Sep 2004 17:37:50 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2004 00:37:51 -0000 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. 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. >>I'm tempted to say that after a certain point the failure results in an >>exit().. >> >> I can't find any reference as to what other OS's do but I'll keep looking. >Sure. If it does manage to return to userland with an error, though, >the program should behave just as it did before the exec() call. That >means that anything that the UTS does in preparing for the exec() >should be undoable after a failed exec(). That's why I want to avoid >stopping or killing threads in the UTS prior to the exec(); it's just >plain messy, and then even worse trying to undo it. >