Date: Tue, 21 Sep 2004 17:37:50 -0700 From: Julian Elischer <julian@elischer.org> To: Daniel Eischen <deischen@freebsd.org> Cc: threads@freebsd.org Subject: Re: SIGILL @ pthread_create() after execv Message-ID: <4150C95E.4030407@elischer.org> In-Reply-To: <Pine.GSO.4.43.0409211700540.26864-100000@sea.ntplx.net> References: <Pine.GSO.4.43.0409211700540.26864-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4150C95E.4030407>