Thus spake Nathan J. Williams ("NJW> ") sometime Today...

NJW> I'm fine with explicitly preventing vfork() in threaded programs, but
NJW> you should convince me of the benefit over just crashing the
NJW> program. I don't think that returning an error is useful; my
NJW> experiences so far debugging threaded applications in particular is
NJW> that errors are generally not checked and the program will just crash
NJW> later anyway.
NJW>
NJW> Why do you think that a threaded program *would* ever call vfork()
NJW> explicitly? What does it expect would happen? The vfork() function is
NJW> a tricky speed hack for certain well-controlled situations; my claim
NJW> is that a multithreaded application is well outside that realm of
NJW> control.

FWIW, under Solaris, only the thread that calls vfork() blocks; the other
threads keep running:

     In a multithreaded application,  vfork()  borrows  only  the
     thread  of  control  that called vfork() in the parent; that
     is, the child contains only one thread. The use  of  vfork()
     in multithreaded applications, however, is not advised.

And, of course:

  NOTES
     The use of vfork() for any purpose other than as  a  prelude
     to  an immediate call to a function from the  exec family or
     to  _exit() is not advised.

Does this help in plotting a course, or is it just noise?  (It's from
Sol9, in case anyone is wondering.)

				--*greywolf;
--
NetBSD: My Computer Runs!