Review request for 5049299 (original) (raw)

Roland McGrath roland at redhat.com
Sun Jun 28 02:33:45 UTC 2009

I am a bit surprised that you see that failure mode, and it's possible it indicates an actual bug in pthread_getattr_np that you could find some other (kosher) way to provoke. But it is generally true that if you use -lpthread then attempting using clone() with CLONE_VM on your own at all is not a reasonable thing to expect to work.

I get the impression that all you are trying to do is spawn an exec'd process in some fashion where you need to do a little bit more work on the child side than just exec alone, but not much. This is exactly the case that vfork exists to optimize, and I am rather shocked and amazed that you should ever have considered anything else before just using vfork. Aside from the portability issues, that is just the simplest and easiest option by far.

I am bemused that you cite "dire warnings" about use of vfork, but are less dissuaded from something so deep in the bowels of Linux implementation, so under-specified, and so hard to use as clone. Perhaps you didn't notice any comparable dire warnings about clone because it never occurred to anyone that someone who needed to be warned would ever stumble into a thicket normally so hidden from view, and so obviously fraught with peril, as clone. The vfork caveats are suitably dire indeed--strongly indicating that the only proper use of vfork is precisely the use you need it for--but these same warnings have been posted and remained consistent since the invention of vfork in 4.2BSD something like 25 years ago.

Thanks, Roland

More information about the core-libs-dev mailing list