lkml.org 
[lkml]   [2000]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SCO: "thread creation is about a thousand times faster than on
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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.103 / U:0.400 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site