> > 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/