[9fans] adding separate rendezvous space to Plan9

[G. David Butler gdb@dbSystems.com]

I added a new flag to rfork() yesterday.  (This one is ok; really!)

The name RFCRENDG (RForkCleanRENDezvousGroup) is compatable with
the others like RFCNAMEG.  There is no RFRENDG because copying the
rendezvous space is not helpful.  If the flag is not specified
the rendezvous space is shared.

This was necessary to enhance the user-space lock stuff I added for C.
In liblock I added qlock(), rlock(), incref() and friends.
I needed RFCRENDG because I used rendezvous to implement qlock
and the rendezvous space can get dirty.

I did that because many of the C library functions, for example, are
not safe to call from processes rforked with RFMEM.  After thinking
about it for a while I decided that instead of making every program
pay for the possibility of RFMEM, I would enhance the lock library
to make it easy to add protection around the unsafe calls.  If you
look at the malloc.c in the ndb source, you will see what I mean.
Instead of what was done in ndb, just surround calls to malloc()
and free() with either lock() and unlock() or qlock() and qunlock()
depending on the need of that program.

I found two other problems.  In /sys/src/ape/lib/ap/plan9/sys9.h there
is a reference to RFREND.  I guess someone thought this was a good
idea too, but did not follow through.  The name does not match the
others so I used RFCRENDG.  Should I ask what Inferno or that other
thing uses?  Do I care?

And in /acme/bin/src/win.l there is a RFMEM in the first rfork() in
the routine run() that shouldn't be there.  (I found this when I
reordered the Ebadarg tests in the rfork system call in the kernel.)

I only found two places that had to change as a result, a RFCRENDG
was added to newns() in the libauth libraries for both C and alef.

I'm sure there are other places in, especially, alef code to take
advantage of the new flag, but not necessary.

David Butler
gdb@dbSystems.com