Messages in this thread | | | Date | Sun, 27 Aug 2000 07:10:32 -0700 | From | Mitchell Blank Jr <> | Subject | Re: SCO: "thread creation is about a thousand times faster than on |
| |
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. Or if my master kernel-thread idea gains favor it could be pushed into there. I'm starting ot think that's the way - that way execve attempts are automatically serialized.
> The previous version of the standard had this right - just leave it > undefined and let the OS try to do something sane. Hopefully this part > will get nixed before the final revision. > > Are you sure? I don't have a copy of ISO/IEC 9945-1:1996 (the
Neither do I... I was just basing me comments on: 1. Victor's statement that MT execve was undefined (unless I just missed some of the context) 2. My memory (which is prone to bit-errors every so often) I could easily be wrong though..
> The requirement makes sense to me, from a > user standpoint.
It would make the most sense for it to just surplant the thread that called it, I think. I don't see what the value of having all the other theads asyncronously disappear is.
-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/
| |