Re: SCO: "thread creation is about a thousand times faster than on

From: Mitchell Blank Jr (mitch@sfgoth.com)
Date: Mon Aug 28 2000 - 00:09:21 EST


Linus Torvalds wrote:
> >Well I guess we'll need a per-thread-group execve semaphore to keep multiple
> >threads from execve'ing on different CPUs.
>
> Oh, Gods. NO!
>
> Linux actually has well-defined semantics for "execve()" in a thread.
> They are very simple:
>
> - the thread executes the execve().
>
> Got it? I know it's a radical idea, but hey, it makes sense to me.

Yes, I "got it". If you lookback a few messages you'd see that that's
exactly what I said it SHOULD work like. However, it was then pointed
out that this wasn't what POSIX mandated (urgh) and then I started trying
to think what would be needed to make that work. I'm not saying normal
happy clones would use this, just CLONE_PID_POSIX_ME_HARDER threads.

> Now, if the question is "Ok, I'm a POSIX thread, and I want the stupid
> POSIX behaviour where an execve() kills all other threads", then you
> have to do it by hand. Something like "kill all other threads, and then
> do the execve". It's not rocket science.

Yes, but:
  * If we're going to give POSIX threads the illusion of a shared PID then
    to be strictly correct the exec'ed process needs to have that PID too.
    If we want to do this, then an execve from any random thread won't
    do.

  * What happens if the execve fails? I suspect POSIX would want us to
    return an error code to that thread without interfering with the
    existing threads. But wait, we've already "kill -9"'ed them all.
    To get this right would definately require kernel support. The
    kernel must atomically end all the other threads when it knows the
    execve isn't going to return an error.

Luckily, under my "master kernel thread" theory this isn't THAT hard -
just evaluate the execve and when you know it will succeed make the

> Anyway, I personally think that it is
> (a) meaningful
> (b) sensible
> (c) unambiguous
> to have a threaded program where one thread executes a new process.
> That thread will become the new proces, all the other threads will be
> utterly, completely and totally unaffected by the fact that one thread
> decided to do something else.
>
> Why would you ever do something like this? Imagine that you're a server,
> and you have the "one thread per connection" approach to life. Further,
> imagine that the connection asks you to execute perl. So you do so.

Absolutely. These are the sane semantics for native threads.

-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:20 EST