Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!uvaarpa!mcnc!decvax!mandrill!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon Allbery)
Newsgroups: comp.unix.wizards
Subject: Re: Shared Memory in BSD4.3 is lacking?
Message-ID: <7460@ncoast.UUCP>
Date: 5 Mar 88 16:49:34 GMT
References: <9100@ism780c.UUCP> <2329@umd5.umd.edu> <2009@ho95e.ATT.COM> <2368@umd5.umd.edu>
Reply-To: allbery@ncoast.UUCP (Brandon Allbery)
Followup-To: comp.unix.wizards
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 42

As quoted from <2368@umd5.umd.edu> by chris@trantor.umd.edu (Chris Torek):
+---------------
| >Much of the problem with the interface is that your program has
| >to find and hook up to shared memory somehow, and the shared
| >memory has to be able to stick around when unused.
| 
| Now, name something that any Unix program can find, and that sticks
| around when unused (at least until you run `rm' ...  oops, I think
| I just gave it away :-) ).  *Why* does SysV use an entirely separate
| name space for shared memory?  (Answer: because it was easy to
| write that way.)
+---------------

Have a go at the Xenix V manuals.  Xenix uses "name files" for shared memory
and semaphores... but the namespace is the ONLY thing they have in common.
I suspect that using the file namespace isn't a good idea unless the entire
process-memory concept is attached to the file namespace (e.g. /proc), but
then you have the question of why some kinds of "files" can have parts shared
between them (/proc + shared memory) but others (everything else) can't.  I
would argue for making it as orthogonal as possible if you're using the file
namespace, but it doesn't make much sense in most cases.

Besides, what exactly is the meaning of "cat /etc/passwd > /tmp/myshmem"?
Should it be allowed by non-root?  By root (using directories as the example
here)?  Only if no process has attached the memory?  Or does opening it attach
it -- in which case why not go all the way and allow any file to be attached,
Multics-style?

+---------------
| way.)  Finally, there is, it seems, no way to have sbrk and shm*
| co-operate.  The future BSD shared memory will cure all of these
| defects, or at least we think so....
+---------------

How?  Seems to me that there IS no cure except to allow overlapping PTEs;
and that sounds like it could open up a nasty can of worms...  Or you can
have multiple address spaces, which brings you back to square one ("WHY
did they use a different address space when there's already a perfectly good
one around and it's (incompatible|inconvenient) for older programs?").
-- 
	      Brandon S. Allbery, moderator of comp.sources.misc
       {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery