qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Fix vfork() syscall emulation


From: Kirill A. Shutemov
Subject: Re: [Qemu-devel] [PATCH] Fix vfork() syscall emulation
Date: Sat, 20 Sep 2008 17:38:12 +0300
User-agent: Mutt/1.5.18 (2008-05-29)

On Sat, Sep 20, 2008 at 04:35:25PM +0200, andrzej zaborowski wrote:
> 2008/9/20 Kirill A. Shutemov <address@hidden>:
> > On Sat, Sep 20, 2008 at 03:52:55PM +0200, andrzej zaborowski wrote:
> >> 2008/9/20 Kirill A. Shutemov <address@hidden>:
> >> > So, implementation vfork() using pthread is wrong.
> >>
> >> Agreed, but implementation of vfork() using fork() is wrong, too.
> >
> > Why?
> >
> > man 2 vfork():
> >
> > BUGS
> >       It  is  rather  unfortunate  that Linux revived this specter from the
> >       past.  The BSD man page states: "This system call will be  eliminated
> >       when  proper system sharing mechanisms are implemented.  Users should
> >       not depend on the memory sharing semantics of vfork() as it will,  in
> >       that case, be made synonymous to fork(2)."
> >
> > If any program doesn't work with vfork() implemented using fork(). it's
> > program bug.
> >
> >
> >> If
> >> we allow a hack, it should be commented, the second thing that needs
> >> to be commented is why the value of CLONE_VM flag is ignored if
> >> CLONE_VFORK is set -- on Linux it's not ignored.
> >
> > vfork() is a hack itself. It was introduced when fork() was very expensive.
> 
> Ok, perhaps I'm nit picking.  clone(2) specifies some semantics for
> CLONE_VFORK regardless of the purpose and this implementation is
> nowhere near these semantics.  I'll just add the same comment that
> klibc has and push the patch.

Thanks!

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]