lkml.org 
[lkml]   [2002]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] clone_startup(), 2.5.31-A0

    On Tue, 13 Aug 2002, Christoph Hellwig wrote:
    >
    > First the name souns horrible. What about spawn_thread or create_thread
    > instead? it's not our good old clone and not a lookalike, it's some
    > pthreadish monster..

    This one definitely isn't a pthread-specific problem. The old UNIX fork()
    semantics for <pid> returning really are fairly broken, since the notion
    of returning the pid in a local register is inherently racy for _anything_
    that wants to maintain a list of its children and needs to access the list
    in the SIGCHLD handler.

    (Simple explanation: imagine a child that exits so quickly that the parent
    hasn't even had time to do the "store pid into the array" before the
    parent is already signalled with SIGCHLD. Yes, this happens, and yes, it's
    a real problem. It wasn't that long ago that bash would _crash_ on this).

    With a system call like this, the parent can
    - allocate the new child information block first
    - do the fork with the pid pointer pointing into the child information
    block.
    - when SIGCHLD for that child comes in, all state will have been set up
    with no races.

    Note how this isn't even thread-specific: it very much would work with a
    regular fork-like approach and a standard shell.

    > > with the help of this syscall glibc's next-generation pthreads code
    >
    > have you discussed this code with IBM's pthread group? I think we don't
    > want to add a new syscall that is only useful to glibc..

    I agree that the name is a bit ugly, but this is a system call that I
    actually think is fundamentally useful (ie I can see how it would be
    totally usable quite outside any specific library implementation issues).

    Talking it over with the IBM threading guys is still worthwhile, though.
    There may be _other_ information that the IBM guys have problems with, and
    it could easily be that the interface we really want is even more generic.

    Linus

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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