Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!purdue!umd5!trantor.umd.edu!chris
From: chris@trantor.umd.edu (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Shared Memory in BSD4.3 is lacking?
Message-ID: <2368@umd5.umd.edu>
Date: 28 Feb 88 10:23:18 GMT
References: <9100@ism780c.UUCP> <2329@umd5.umd.edu> <2009@ho95e.ATT.COM>
Sender: ris@umd5.umd.edu
Reply-To: chris@trantor.umd.edu (Chris Torek)
Organization: University of Maryland, College Park
Lines: 45

>In article <2329@umd5.umd.edu> I wrote:
>:Anyway, BSD does not have System V style shared memory ... because
>:System V shared memory is wrong.  (Now there is a good flammable
>:statement for you :-) )

In article <2009@ho95e.ATT.COM> wcs@ho95e.UUCP
(46323-Bill.Stewart,2G218,x0705,) writes:

[For what *are* all those numbers in your name, anyway? :-) ]

>Ok, I'll flame!  What's wrong with System V shared memory?

You name it yourself.  First:

>I agree that the user interface is annoying,

(It feels like something IBM might have invented.)

>having chosen clunky-but-general over cleaner-but-less-general,

There are cleaner approaches that are still general.  While it is
true that most hardware restricts sharing to page-sized or larger
segments, finding sharable locations in SysV is not at all easy.
Moreover:

>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.)

Additionally, the total number of shared pages allowed is, I believe,
compiled into the kernel.  (There are a number of similar grotesqueries
in the 4BSD kernel, again because it was easy to implement that
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....
-- 
In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163
(still on trantor.umd.edu because mimsy is not yet re-news-networked)
Domain: chris@mimsy.umd.edu		Path: ...!uunet!mimsy!chris