On Sep 10,  4:02pm, nathanw@wasabisystems.com ("Nathan J. Williams") wrote:
-- Subject: Re: popen reentrant (was Re: SA/pthread and vfork)

| > Absolutely not. We should either not allow vfork() on threaded programs
| > having it return SIGSYS, or make it work properly. Relying on threaded
| > programs `knowing' that they should not call vfork() is a recipe for
| > disaster. Finally, having vfork() work is easy enough...
| 
| I'm fine with explicitly preventing vfork() in threaded programs, but
| you should convince me of the benefit over just crashing the
| program. I don't think that returning an error is useful; my
| experiences so far debugging threaded applications in particular is
| that errors are generally not checked and the program will just crash
| later anyway.

The benefit is that you get an consistent behavior instead of going ahead
with an operation that may or may not work, depending on the phase of the
moon.

| Why do you think that a threaded program *would* ever call vfork()
| explicitly? What does it expect would happen? The vfork() function is
| a tricky speed hack for certain well-controlled situations; my claim
| is that a multithreaded application is well outside that realm of
| control.

It might call it though a 3rd party library. It might want the semantics
of vfork(). I don't know. But having a semi-functional vfork() that randomly
causes stack corruption is the worst situation [one situation is having
no vfork() and another is having working vfork()]

christos