[lkml]   [2000]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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