shmem implementation

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Several observations so I can finish the Win32 code that's sat on my machines
for the last four months...


1. Win32 allows both anon mapping (keyed into the swap file itself) and file based
   mapping.  We have no concept of key based mapping, since handles to shmem are
   very process specific and the handles themselves can't be shared.  I suppose
   a key-based mapping could be the name of a swap-file anon segment with the
   "apr_" prefixed to the numeric value, but that might be rather silly.

2. Win32 further supports naming file maps.  That is, once a mapping to a file or
   into the swap file is created, other processes simply open that named map.  This
   isn't the file name, this is the name given by the creator to the file mapping.

3. Even on unix, the concept of getting the 'named' key and setting it once again
   based on an abstract type strikes me as entirely bogus, here would be my
   recommendation:  if apr doesn't support named mapping at all, APR_ENOTIMPL instead 
   of APR_ANONYMOUS (it's obvious) from apr_get_shm_name.  Otherwise, always return 
   a string, even if it's the ascii representation of the key_t value.  Conversly, on 
   apr_set_shm_name, convert that numeric ascii string back to a key_t.  This becomes 
   an internal instead of external abstraction.  The other anon option is to return
   an empty string, and setting the name to the empty string yields APR_SUCCESS.

In general, I don't really believe the apr_shmem implementation is abstract enough
for general, everyday use.  We are under the silly impression that users want only
-one- kind of shmem at a time, which is obviously absurd.  If we are just looking
to kick around a 64kb segment, anon memory (implemented on win32 as swap file mem)
is just fine, thanks.  If we are going to pass around the passphrases to a bunch
of secrets, we probably want file based shmem and store it in the secure temp
directory with a randomly generated name (coming back to the mkstemp issue :-)

I'd like comments on this before I proceed further.

Bill