Messages in this thread |  | | Date | Sun, 27 Aug 2000 22:09:21 -0700 | From | Mitchell Blank Jr <> | Subject | Re: 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/
|  |