Re: Review request for 5049299

[Martin Buchholz <martinrb at google dot com>]

Let's try that again, with evil mime stuff removed.


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