lkml.org 
[lkml]   [1999]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Porting vfork()
    On Thu, 7 Jan 1999, Alan Cox wrote:

    > > My intent in this thread was to gage the vfork() impact. It makes no sense
    > > to commit time developing a kernel solution if only a very few applications
    > > have such silly dependencies.
    >
    > I think you can fix it in libc. Make vfork() do a clone with CLONE_VM and
    > leave a small gap in the stack for the parent to use.
    >
    > In the client we run as before. The parent waits on a pthread mutex of some
    > sort which libc can clean up on exit, or exec (I belive those are the right
    > cases ?). I guess it needs to block all signals too.

    How do you release a mutex only on a _successful_ execve()?

    > So in theory its doable in glibc if anyone is feeling extremely clever

    It's fairly simple in the kernel, and I wouldn't mind seeing it in there.
    It inevitably will be more complex in libc, and I'm not sure whether it'd
    be trustable. The kernel version is completely portable, too.

    Why? Why not. It's minor, and if we get it right, every time someone asks
    how vfork() is supposed to work, you get to point them at Linux. ;-)

    --
    Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)



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

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