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