On Sun, Aug 05, 2012 at 11:54:32PM +0200, Jilles Tjoelker wrote: > On Mon, Jul 30, 2012 at 01:53:03PM +0300, Konstantin Belousov wrote: > > On Mon, Jul 30, 2012 at 12:24:08PM +0200, Jilles Tjoelker wrote: > > > People sometimes use system() from large address spaces where it would > > > improve performance greatly to use vfork() instead of fork(). > > > > A simple approach is to change fork() to vfork(), although I have not > > > tried this. It seems safe enough to use sigaction and sigprocmask system > > > calls in the vforked process. > > > > Alternatively, we can have posix_spawn() do the vfork() with signal > > > changes. This avoids possible whining from compilers and static > > > analyzers about using vfork() in system.c. However, I do not like the > > > tricky code for signals and that it adds lines of code. > > > > This is lightly tested. > > > It is interesting to note that for some time our vfork(2) no longer > > stops the whole forked process (parent), only the forking thread is > > waiting for the child exit or exec. I am not sure is this point > > important for system(3), but determined code can notice the difference > > from the fork->vfork switch. > > Neither fork nor vfork call thread_single(SINGLE_BOUNDARY), so this is > not a difference. It is the difference, because vforked child shares parent address space.
> > Thread singling may be noticeable from a failing execve() (but only in > the process doing execve()) and in the rare case of rfork() without > RFPROC. No, other running threads in parent affect vforked child till exec or exit. In fact, I would classify this as bug, but not a serious one.
pgpgli27fNMY8.pgp
Description: PGP signature
