On 07-Apr-98 Greg A. Woods wrote:

>> The CSRG 4.4BSD book has murky grumbling about programs exploiting the
>> vfork() shared vmspace showing "bad programming practice", or some such. 
>> That's the only clue I've seen.
>
> You mean the bit in section 5.6 where they discuss that even though
> vfork() is likely to remain more efficient than any copy-on-write scheme
> the CSRG folks took it out and simply implemented it as fork() because
> it is bad programming practice to allow a child process to modify the
> parent's address space?  Yes of course some programs did do this and
> naturally they broke when compiled on original 4.4BSD.

That's the passage, alrighty.

To start, as long as a call and its design behavior are defined and documented,
I fail to see the "bad programming practice" if people exploit the behavior in
ways perhaps not envisioned for the design.  It's the party who arbitrarily
decides to alter the defined behavior who is pursuing "bad programming practice"
there, unless of course there's a "good reason" -- and none was articulated
in this case.  (Or none that I've seen.)

> My personal opinion is that vfork() is still an abomination and no
> modern OS should support it -- copy-on-write is close enough that we
> should not need to rely on stupid tricks for minor performance gain,
> esp. when this teeter-totter dependence on semantics happens.  The
> 4.4BSD release was correct to obliterate it.

But they didn't offer anything better.

If you mean that the original vfork() was a "stupid trick", I think I'd say
that do an exec, fork() would be even more so.

I also think there's more than just a minor performance gain at issue here. 
The copy-on-write behavior of the 4.4BSD vfork() causes all kinds of havoc in
the vm system.  That havoc doesn't go away with an execve(), and duplicate
pages pile up.  I haven't thoroughly evaluated just how big a problem yet, but
there's no question a shared vmspace vfork() would/should alleviate a problem
for the vm (whichever vm you use).

Elsewhere in the same book, the same authors are complaining about the
copy-on-write mechanisms in the Mach vm, and suggesting THAT behavior might be
eliminated from future releases of the OS!


--Jim Howard  <jiho@mail.c-zone.net>


----------------------------------
E-Mail: jiho@mail.c-zone.net
Date: 07-Apr-98
Time: 09:54:44

This message was sent by XFMail
----------------------------------