[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
    In article <>,
    Mitchell Blank Jr <> 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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:38    [W:0.023 / U:1.364 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site