>> 2) When the parent can no longer assume (and requires) that the
>> child will be dispatched and execve prior to the parent
>> receiving control back from vfork()... a subtle race condition
>> porting problem arises.
>
> I can't think of an easy way to make this work...
Linus posted a basic roadmap. Without this, the shared VM is insane.
>> My intent in this thread was to gage the vfork() impact.
>
> We've go this far without it -- and it is a bit of a hack. I don't
> see why we should need to add it now. We should be able to fix a
> small handful of applications, and almost any OS can use fork()
> without too much penality as most implement COW.
NetBSD has a "Why implement traditional vfork()" page that explains
why they reimplemented vfork(). It seems vfork() is still good.
http://www.netbsd.org/Documentation/kernel/vfork.html
-
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/