Jason Thorpe <thorpej@nas.nasa.gov> writes:

  > 	* The original pre-4.4BSD vfork(2) semantics are now specified
  > 	  in XPG4.2.  This means that new systems that want to carry the
  > 	  UNIX(tm) trademark must implement the address space-sharing
  > 	  semantics.  I.e. the interface is compatible with the rest of
  > 	  the industry.

It is amazing how different people can read the same thing and get
markedly different interpretations. My reading of the SUS (if that is
not definitive XPG4.2 I have no doubt I will be corrected :-) ) is
that the 4.2/4.3 vfork semantics are allowed but *not* required.

To suggest otherwise is to only encourage people to depend on the
sharing/blocking semantics when they shouldn't because they are *not*
guaranteed.

To be clear, I am not advocating taking vfork back out though I gather
that would make some others happy. I do think it would be nice if
there was an easy way to turn of vfork semantics for portability
testing, but I don't think this is so desirable I am going to go out
and impliment it tomorrow.

All I am advocating is that the warning in the man page not to depend
on the shared memory sematics remain (someone suggested it could go)
and further that a warning about not depending the parent blocking
semantics be added. (Interestingly the SUS does not mention the parent
blocking).  I also think a conscious effort should be made to keep
NetBSD user programs free of dependancies on the vfork
blocking/sharing semantics as part of a general quality of
implimentation issue.


  > 	* There is a noticeable performance improvement, especially
  > 	  for large processes, e.g. make(1) bulding the C library or
  > 	  kernel.

Hmm. If I was looking to speed up making the C library the first place
I'd look is make itself (unless make has been improved recently).
Obviously I can't use gmake on the netbsd tree, but everywhere else,
gmake gives me a *significant* speed improvement over make.

Ian