[ On Wednesday, July 9, 2003 at 11:13:02 (-0700), Matt Thomas wrote: ]
> Subject: Re: fsync performance hit on 1.6.1
>
> I forwarded Bill Gallmeister your message, and he gave me the following
> to use as a response:
> 
> And to comment on the email thread you forwarded:  hindsight's a beautiful
> thing.  shm_open et al were designed to allow a trivial implementation atop
> mmap (or atop the Ludicrous Sys V Interface (TM)), but at the time we came up
> with the standard, I believe it was only the rocket scientists at Sun who had
> mmap--no one else had ponied up to the memory==file proposition and all its
> implications.  There wasn't even an INTERNET back then, for Chrissake.  Al Gore
> hadn't been BORN.  We wrote the damn standard using OIL LANTERNS.  Okay, maybe
> I'm exaggerating a little.  It was a DECADE ago!

Thanks for that!  I've had Bill's book open here on my desk for other
reasons lately and when this came up here I did a rough page count of
each section and while doing so I was reading all the "this is tricky"
disclaimers.  :-)

How quickly people forget their heritage though.  By that I mean if Unix
people of the day had not forgotten their Multics background then the
"memory==file" proposition would not have been so strange and its
implications would have been well understood by them.  I was an avid
user of Multics right up to the day I first learned to use SysV IPC so
perhaps thats why it never confused me or made me cringe.

The SysV IPC mechanisms have had a long, and IMVNSHO greatly undeserved,
history of being decried, discredited, and disparaged.  I suspect this
would have happened to SHM in particular even if it had not shared the
ipcs/ipcrm resource identifier namespace quirks of message queues and
semaphores simply because of the stupid politics separating USL and the
BSD/CSRG crowds at the time (and still :-).

Regardless POSIX shared memory is still effectively stuck with a flat,
invisible, namespace that now looks ever so much more like a flat
filesystem but has almost none of the utitlity.  I.e. there's a long and
vast gap between the goal of making POSIX shared memory capable of being
implemented on top of either true mmap() or SHM, but in the end the
final standard leaves an application author hanging high and dry because
the restrictions required for portable applications are so ludicrous
that it's almost infinitely easier for the application to independently
support both variants instead of trying to contort through the POSIX API.
(and in modern systems that almost invariable means just using SHM).

In some senses it was also unfortunate that the POSIX Realtime working
group got stuck with defining IPC mechanisms, but of course that seemed
to be just more fallout from the stupid USL vs. BSD politics.  The
X/Open guys had a much more, well, open, attitude.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>