In article <20000827071032.D55996@sfgoth.com>,
Mitchell Blank Jr <mitch@sfgoth.com> wrote:
>Mark Kettenis wrote:
>> Grumble... and I suppose a failed execve() needs to return an error
>> to that one thread, but a succesful one needs to atomically destroy all
>> the other threads... And HOW is this supposed to be implemented?
>>
>> Well, that isn't explicitly demanded by the standard, but I don't
>> thing any other behaviour would make much sense.
>
>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. I
asked myself the question "What should execve() do inside a thread?",
and the voices in my head told me that "It should execve() the program
it asked for, stupid".
I always follow the voices in my head. They tend to be right, most of
the time.
Anyway, somebody else asked "Well, what about the other threads?", and
th evoices in my head said "Oh, do they want to execve() too? Sure, they
can do that if they want to".
Stunningly simple.
The fact that POSIX seems to have trouble with this, is purely due to
POSIX. Please don't think that execve() is somehow "hard" to do. It's
exactly the same case as it always has been. The process drops the old
VM context (other threads can continue to use it - why not?) and assumes
a new one. Simple.
No semaphores needed.
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.
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.
Linus "threads aren't as perverse
as POSIX has made them" Torvalds
-
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