My thinking on vfork/clone was affected by:<br><br>---<br> the solaris man page says<br><a href="http://docs.sun.com/app/docs/doc/816-5167/vfork-2?a=view">http://docs.sun.com/app/docs/doc/816-5167/vfork-2?a=view</a><br><br>
The use of <kbd><b>vfork()</b></kbd> in multithreaded applications,
however, is unsafe due to race conditons
that can cause the child process to become deadlocked and consequently
block both the child and parent process from execution indefinitely.<br><br>(In fact, I'm still afraid that one of those race conditions will kill the vfork option<br>even on Linux)<br><br>That man page also says,<br>
<br>The <kbd><b>vfork()</b></kbd> function is deprecated. Its sole legitimate use as a prelude to an immediate call to a function from the <tt>exec</tt> family can be achieved safely by <a href="http://docs.sun.com/app/docs/doc/816-5168/posix-spawn-3c?a=view">posix_spawn(3C)</a> or <a href="http://docs.sun.com/app/docs/doc/816-5168/posix-spawnp-3c?a=view">posix_spawnp(3C)</a>.<br>
<br>But...posix_spawn doesn't give you any way to delete *all* file descriptors<br>and if you try to collect them before spawning, there is a race in a multithreaded program.<br><br>(Aside: I also wonder why glibc's implementation of posix_spawn avoids using vfork<br>
if there are file actions specified)<br><br>---<br><br>Linux clone has avoided vfork's bad press, and has occasionally been<br>described as "elegant".  For a while I believed that clone() was the only<br>system call that created new processes, and that vfork() was just an<br>
inflexible special case of clone(), and on ia64 that appears to be true,<br>but on x86 clone(), fork() and vfork() are separate system calls, <br>and glibc has different gobs of assembly code around each.<br><br>In particular, glibc's clone fiddles with TIDs even when CLONE_THREAD <br>
is not specified, while vfork never does.  That feels like a bug.<br><br>~/src/glibc-2.10.1 $ for x in vfork clone; do echo --- $x --- ; find -name $x.S | xargs grep -l -i tid; done<br><br>--- vfork ---<br>--- clone ---<br>
./sysdeps/unix/sysv/linux/s390/s390-64/clone.S<br>./sysdeps/unix/sysv/linux/s390/s390-32/clone.S<br>./sysdeps/unix/sysv/linux/x86_64/clone.S<br>./sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S<br>./sysdeps/unix/sysv/linux/powerpc/powerpc32/clone.S<br>
./sysdeps/unix/sysv/linux/i386/clone.S<br>./sysdeps/unix/sysv/linux/sh/clone.S<br>./sysdeps/unix/sysv/linux/sparc/sparc32/clone.S<br>./sysdeps/unix/sysv/linux/sparc/sparc64/clone.S<br><br>I'm still hoping we can fix something in glibc.<br>
<br>Martin<br><br><div class="gmail_quote">On Sat, Jun 27, 2009 at 19:33, Roland McGrath <span dir="ltr"><<a href="mailto:roland@redhat.com">roland@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I am a bit surprised that you see that failure mode, and it's possible it<br>
indicates an actual bug in pthread_getattr_np that you could find some<br>
other (kosher) way to provoke.  But it is generally true that if you use<br>
-lpthread then attempting using clone() with CLONE_VM on your own at all is<br>
not a reasonable thing to expect to work.<br>
<br>
I get the impression that all you are trying to do is spawn an exec'd<br>
process in some fashion where you need to do a little bit more work on the<br>
child side than just exec alone, but not much.  This is exactly the case<br>
that vfork exists to optimize, and I am rather shocked and amazed that you<br>
should ever have considered anything else before just using vfork.  Aside<br>
from the portability issues, that is just the simplest and easiest option<br>
by far.<br>
<br>
I am bemused that you cite "dire warnings" about use of vfork, but are less<br>
dissuaded from something so deep in the bowels of Linux implementation, so<br>
under-specified, and so hard to use as clone.  Perhaps you didn't notice<br>
any comparable dire warnings about clone because it never occurred to<br>
anyone that someone who needed to be warned would ever stumble into a<br>
thicket normally so hidden from view, and so obviously fraught with peril,<br>
as clone.  The vfork caveats are suitably dire indeed--strongly indicating<br>
that the only proper use of vfork is precisely the use you need it for--but<br>
these same warnings have been posted and remained consistent since the<br>
invention of vfork in 4.2BSD something like 25 years ago.<br>
<br>
<br>
Thanks,<br>
<font color="#888888">Roland<br>
</font></blockquote></div><br>