Review request for 5049299

[Martin Buchholz]

Roland,

You write "It's all the same "clone" code in the kernel."
and that may be true, but I'm thinking about the glibc wrappers around them.
In particular, it seems to me that vfork and clone(CLONE_VM|CLONE_VFORK)
should have similar assembly wrappers around them.  But the
vfork code uses SAVE_PID/RESTORE_PID which frobs only the pid, not the tid,
while clone used RESET_PID which frobs both the pid and tid.
It seems to me they should share common infrastructure.

Martin

On Mon, Jun 29, 2009 at 19:28, Roland McGrath <roland at redhat.com> wrote:

>
> > Linux clone has avoided vfork's bad press, and has occasionally been
> > described as "elegant".  For a while I believed that clone() was the only
> > system call that created new processes, and that vfork() was just an
> > inflexible special case of clone(), and on ia64 that appears to be true,
> > but on x86 clone(), fork() and vfork() are separate system calls,
> > and glibc has different gobs of assembly code around each.
>
> Internally it's true.  On some machines there are separate vfork and/or
> fork calls, some not.  If you are worried about what the semantics mean,
> it is immaterial which system call number you used and how many arguments
> you passed.  It's all the same "clone" code in the kernel.
>
>
> Thanks,
> Roland
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090630/af629931/attachment.html>