> Isn't the simple solution, for pthreads, just equate __vfork = _sys_fork
> in libpthread.  Any use of vfork(2) should be able to be replaced by
> fork(2)
> with no change in behavior.   The sharing of address space is an
> optimization, not a communications mechanism.  Any applications that
> breaks is broken and needs to be fixed.

not quite.  The child's libc is still configured to run threaded
(__isthreaded set and libpthread strong aliases on many functions) and some
functions (all/most FILE* functions for instance) can block and then run
libpthread code.  This is why we need reentrant popen (and system) in any
case and probably some fork wrapper which resets libc/libpthread in the
child.

I think it's reasonable to substitute fork for vfork in threaded apps.  On
the other hand I also think that we should provide a best effort vfork
implementation.  The current situation where vfork can trash the child's
stack through upcalls in the parent is not good and should be remedied,
wether we substitute fork for vfork in out libpthread or not.  Some other
threading library might deal better with the situation and thus our kernel
should at least allow this.  FWIW I think our libc/libpthread would work
with real vfork for popen/system and the simplest vfork/exec usage.

    christian