In article <20030914212044.GA25197@moghedien.mukappabeta.net>,
Matthias Buelow <mkb@mukappabeta.de> wrote:
>
>Not without interruption.  It has been "removed" in 4.4BSD (in that it
>uses ordinary fork and only suspends the parent).  Maybe they wanted to
>clean up stuff.  Particularly in System V derived systems (but not in
>all of them), vfork is also only emulated with fork, if at all
>present.  I don't remember that some of the systems which do this were
>extraordinarily slow because of that.

Let's not re-write history here. There was an attempt made to remove
vfork in 4.4BSD, not for cleaning up any API, but because it was not
supported by the newly imported mach-vm. That broke csh, since it
depends on the semantics of having the parent stop before finishing 
off setting up the child, so a compromise was reached to make a fake
vfork() that just suspends the parent. This broke csh again :-) in
a different but more subtle way: the hashstat builtin depended on the
sharing of memory space since the child updates the statistics on the
parent process... That was acceptable loss, compared to the amount of
work involved in providing a proper vfork().

>>3.  ugly, how?  It creates a small space for a specific purpose.
>>4.  inelegant?  Hmmm...
>
>It "poisons" the API by adding a system call which doesn't offer any
>additional functionality, only a fast-path optimization for a very
>specific situation.  And even one which someone already proficient with
>fork semantics has to go back to the manual and read up on it, for it
>introduces some traps which the naive programmer can easily fall into,
>so it also violates the principle of least astonishment.

The very specific situation is actually very common. Shells/make executing
programs.

christos