christos@zoulas.com (Christos Zoulas) writes:

> | Again, I think this is the wrong approach. Instead of making vfork()
> | work with SAs, we should consider avoiding vfork() in threaded
> | programs and taking the hit of calling ordinary fork() instead.
> 
> 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.

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.

        - Nathan