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 16:11:39 +0300
User-agent: Mutt/1.5.18 (2008-05-29)

On Sat, Sep 20, 2008 at 02:45:57PM +0200, andrzej zaborowski wrote:
> 2008/9/20 Kirill A. Shutemov <address@hidden>:
> > On Sat, Sep 20, 2008 at 04:56:45AM +0200, andrzej zaborowski wrote:
> >> 2008/9/18 Kirill A. Shutemov <address@hidden>:
> >> > vfork() is a kind of fork, not thread despite CLONE_VM
> >>
> >> According to clone(2) it can be either, the only difference is that
> >> vfork() suspends the parent process.  So if CLONE_VM is set, I think
> >> still the pthread / clone way should be used and the child thread
> >> should be waited on.
> >
> > vfork() suspends the parent process until a call of execve(2) or _exit(2).
> > If child call execnv(2) it replaces whole process, not only the thread.
> > If child call _exit(2) it stops while process, not only the thread.
> 
> Do you mean that's the current behavior in qemu?  That's not what clone(2) 
> says.

Currently, qemu with NPTL(I've tested on ARM EABI) on CLONE_VM create
thread using pthread interface. Every thread has its own stack.

vfork() is clone() with flags CLONE_VM and CLONE_VFORK. 

man vfork(2):

   Linux Description
       vfork(),  just  like  fork(2), creates a child process of the calling
       process.  For details and return value and errors, see fork(2).

       vfork() is a special case of clone(2).  It is used to create new pro-
       cesses without copying the page tables of the parent process.  It may
       be useful in performance sensitive applications where a child will be
       created which then immediately issues an execve(2).

       vfork()  differs  from  fork(2) in that the parent is suspended until
       the child makes a call to execve(2) or _exit(2).   The  child  shares
       all  memory  with its parent, including the stack, until execve(2) is
       issued by the child.  The child must  not  return  from  the  current
       function or call exit(3), but may call _exit(2).

       Signal handlers are inherited, but not shared.  Signals to the parent
       arrive after the child releases the parent's memory.

So, implementation vfork() using pthread is wrong.

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