mikep@ism780c.UUCP (Michael A. Petonic) (02/19/88)
Now, don't get me wrong. I like Berzerkeley and all, but JEEZ! No
shared memory? After implimenting a program to use shared memory in
BSD (from the specs in the "Berkeley Software Architecture Manual (4.3
edition)") and trying to compile it, I notied I'm missing some
functions. So, I look really really really close at the page and
there is a footnote that in effect say "We don't have any of these
functions implemented, yet."
What gives? After trying various methods to communicate information
accross the parent-child barrier, I am convinced that shared memory is
the only way to go.
Can someone more familiar with BSD give me a hand? Is there
a crufty trick I can use with sockets to have *fast* interprocess
communication?
What I'd really like to do is to share a file pointer (that's
right, a file pointer, not a file descriptor) accross processes
along with several variables. Any decent ways out there?
-MikeP
--------
Michael A. Petonic (213) 453-8649 x3247
INTERACTIVE Systems Corporation "My opinions in no way influences
2401 Colorado Blvd. the price of tea in China."
Santa Monica, CA. 90404
{sdcrdcf|attunix|microsoft|sfmin}!ism780c!mikep
additional disclaimer: I'm a System V man out of necessity, so
no "What!?!?! You don't know every detail of sockets and
datagrams???" type flames, please.chris@trantor.umd.edu (Chris Torek) (02/20/88)
(Answer: Yes.) In article <9100@ism780c.UUCP> mikep@ism780c.UUCP (Michael A. Petonic) writes: >Now, don't get me wrong. I like Berzerkeley and all, but JEEZ! No >shared memory? [stuff about mmap deleted] >What gives? Nobody was quite sure how mmap `ought' to work, and it never got implemented. It is likely to be in `4.4', which is not what the next release is going to be. (Thoroughly confused yet?) Anyway, BSD does not have System V style shared memory (which might more accurately be called `USG 3.0 style shared memory') because System V shared memory is wrong. (Now there is a good flammable statement for you :-) ) >What I'd really like to do is to share a file pointer (that's >right, a file pointer, not a file descriptor) accross processes >along with several variables. What kind of `file pointer'? Kernel file pointers (indexed by user file descriptors) are in fact shared. stdio `FILE *'s are not. Basically, under 4.3BSD, you are stuck with a system call per remote variable access (read: slow). You could write a special device driver that cheats, and acts like System V shared memory.... -- In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163 (hiding out on trantor.umd.edu until mimsy is reassembled in its new home) Domain: chris@mimsy.umd.edu Path: not easily reachable
rk9005@cca.ucsf.edu (Roland McGrath) (02/21/88)
["Shared Memory in BSD4.3 is lacking?"] - chris@trantor.umd.edu (Chris Torek): } implemented. It is likely to be in `4.4', which is not what the } next release is going to be. (Thoroughly confused yet?) Okay, I'll give. What *will* the next release be?????? Yes, thank you, I am now thoroughly confused; I guess that's what you wizard/guru types do for fun when you're not describing the universe to us all. -- Dick Karpinski Manager of Unix Services, UCSF Computer Center UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick (415) 476-4529 (11-7) BITNET: dick@ucsfcca or dick@ucsfvm Compuserve: 70215,1277 USPS: U-76 UCSF, San Francisco, CA 94143-0704 Telemail: RKarpinski
libes@cme-durer.ARPA (Don Libes) (02/25/88)
In article <2329@umd5.umd.edu> chris@trantor.umd.edu (Chris Torek) writes: >In article <9100@ism780c.UUCP> mikep@ism780c.UUCP (Michael A. Petonic) writes: >>Now, don't get me wrong. I like Berzerkeley and all, but JEEZ! No >>shared memory? > You could write a special device >driver that cheats, and acts like System V shared memory.... A couple of years ago, I wrote a shared memory server for 4.2BSD. It is all user-level code, and has the advantage of extending the paradigm to multiple machines. I assume it will run on 4.3BSD although I haven't tried to do so. We still use it here, so it's been pretty well banged on and debugged. People like it because it's easy to use, although it is obviously slower than real common memory. It was written up in the Summer 1985 Usenix Proceedings. If anyone is interested I can make it ftp accessable or post it to the net. Don Libes cme-durer.arpa ...!uunet!cme-durer!libes
chris@trantor.umd.edu (Chris Torek) (02/25/88)
>chris@trantor.umd.edu (me): >} It is likely to be in `4.4', which is not what the >} next release is going to be. (Thoroughly confused yet?) In article <1155@ucsfcca.ucsf.edu> roland@rtsg.lbl.gov (Roland McGrath) writes: >Okay, I'll give. What *will* the next release be?????? I wish I knew. Mike Karels had been using the name `4.3a' temporarily, but found that IBM has already used that name for a PC/RT release. In the meantime, I have been calling it `4.3+', `4.3++', and (the latest) `4.3T': T for Tahoe. Anyway, there *is* an update to 4.3BSD in the wings, but it probably will not be called 4.4. Apparently tacking a suffix onto an existing name makes it easier to convince the lawyers to use the same contract, or something. >Dick Karpinski Manager of Unix Services, UCSF Computer Center (So why does not this match the author name listed above?) -- In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163 (hiding out on trantor.umd.edu until mimsy is reassembled in its new home) Domain: chris@mimsy.umd.edu Path: not easily reachable
allbery@ncoast.UUCP (Brandon Allbery) (02/25/88)
As quoted from <2329@umd5.umd.edu> by chris@trantor.umd.edu (Chris Torek): +--------------- | Anyway, BSD does not have System V style shared memory (which might | more accurately be called `USG 3.0 style shared memory') because | System V shared memory is wrong. (Now there is a good flammable | statement for you :-) ) +--------------- Umm, as far as I know, USG 3.0 (== System III) did NOT have shared memory. What exactly is wrong with System V's shared memory? I haven't seen any problems with it, and certainly it's not the pain that Xenix shared memory is (as an example; you can't leave shared memory attached across system calls, even!). Don't take this as a flame: I'm truly interested in what might be lacking. (It works for what I do, but I'm not exactly at the forefront of software/hardware research.) -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery KABOOM!!! Worf: "I think I'm sick." LaForge: "I'm sure half the ship knows it."
arosen@eagle.ulowell.edu (MFHorn) (02/25/88)
In article <2353@umd5.umd.edu> chris@trantor.umd.edu (Chris Torek) writes: >In article <1155@ucsfcca.ucsf.edu> roland@rtsg.lbl.gov (Roland McGrath) writes: >>Okay, I'll give. What *will* the next release be?????? >Anyway, there *is* an update to 4.3BSD in the wings Does anyone know (and can they say) *when* the next release will be? Or what we can look forward to? Judging by the changes in orginization to the file systems just posted to comp.bugs.4bsd.ucb-fixes, it seems like there'll be a lot of changes/enhancements. Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I ULowell, Box #3031 | ulowell!arosen | learned how to make it Lowell, Ma 01854 | | talk" -Thunder Road RD in '88 - The way it should be
wcs@ho95e.ATT.COM (Bill.Stewart) (02/26/88)
In article <2329@umd5.umd.edu> chris@trantor.umd.edu (Chris Torek) writes:
:Anyway, BSD does not have System V style shared memory (which might
:more accurately be called `USG 3.0 style shared memory') because
:System V shared memory is wrong. (Now there is a good flammable
:statement for you :-) )
Ok, I'll flame! What's wrong with System V shared memory?
I agree that the user interface is annoying, having chosen
clunky-but-general over cleaner-but-less-general, but that's not a
major loss. (At least it's less annoying than semaphores.)
So what's missing, or otherwise brain-damaged? 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. The magic cookie approach seems
reasonable.
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcsgwyn@brl-smoke.ARPA (Doug Gwyn ) (02/28/88)
In article <7435@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: >Umm, as far as I know, USG 3.0 (== System III) did NOT have shared memory. Right -- it appeared (along with semaphore and message IPC) in USG 4.0, which seems to have merged these in from earlier UNIX/RT as part of the consolidation of internal AT&T UNIX variants. P.S. I don't know WHAT the "right" way is -- I suspect there isn't one.
chris@trantor.umd.edu (Chris Torek) (02/28/88)
>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
ka@june.cs.washington.edu (Kenneth Almquist) (02/28/88)
In article <7371@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <7435@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: >> Umm, as far as I know, USG 3.0 (== System III) did NOT have shared memory. > > Right -- it appeared (along with semaphore and message IPC) in USG 4.0, > which seems to have merged these in from earlier UNIX/RT as part of the > consolidation of internal AT&T UNIX variants. Not quite. USG has a decent release numbering scheme until the marketing folks messed it up. Once per year, a new release of UNIX would be issued and the first digit of the release would be updated, giving us releases with numbers like 3.0, 4.0, and 5.0. Additional releases were made in the middle of the UNIX year for the benefit of people who wanted new features before the next major release; these were given numbers like 5.1, 5.2, 5.3, and 5.4. A third digit was used for bug fixes, so in parallel with the development of 5.1 through 5.4 we also had releases 5.0.1, 5.0.2, 5.0.3, etc. Occasionally, bug fixes were also issued for intermediate releases; I seem to recall there was a release 4.2.1, for example. System III == USG release 3.0.1 and System V == USG release 5.0.1. Shared memory first appeared in USG release 4.2. Since 5.0 was the first major release containing shared memory and since System V is almost the same as release 5.0, it seems reasonable to talk about shared memory as a system V feature. UNIX/RT also had shared memory, semaphores, and messages, but the system call interface to these features was quite different (no access control, messages were sent to processes rather than to message queues, semaphore operations were limited to P and V, etc.) Kenneth Almquist ka@june.cs.washington.edu
decot@hpisod2.HP.COM (Dave Decot) (02/29/88)
> So what's missing, or otherwise brain-damaged? 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. The magic cookie approach seems > reasonable. But the cookies should be doled out by the file system, not by a replication and distortion of the file system semantics. There still is no useful way to generate appropriate magic cookies under the "shmid" approach; ftok() is a self-admitted botch. There should be a way to cause private shared memory segments to vanish upon termination of a process or process group. Dave Decot hpda!decot
jsm@hpfcdc.HP.COM (John Marvin) (03/01/88)
> There should be a way to cause private shared memory segments > to vanish upon termination of a process or process group. There is a way. Just call shmctl() to remove the id immediately after calling shmat() to attach the private segment. This will cause the memory segment to vanish when the last process that has it attached exits. This also works for "public" shared memory, but it sort of defeats the purpose of it being "public". John Marvin jsm%hpfcla@hplabs.hp.com
rbj@icst-cmr.arpa (Root Boy Jim) (03/01/88)
From: Chris Torek <chris@trantor.umd.EDU> Nobody was quite sure how mmap `ought' to work, and it never got implemented.... .... in BSD. So those vendors who needed it, SUN and Sequent, implemented it *differently*. Encore probably has another variation. I have used both of the SUN and Sequent versions, and am not sure which I prefer. On the other hand, everyone knows how munmap `ought' to work :-) System V shared memory is wrong. Nice to know. I had always suspected as much. I think it will take more than Bill Joy to fix System V. In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163 (hiding out on trantor.umd.edu until mimsy is reassembled in its new home) Domain: chris@mimsy.umd.edu Path: not easily reachable (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 Now I am depressed...
paradis@encore.UUCP (Jim Paradis) (03/02/88)
In article <12033@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: > From: Chris Torek <chris@trantor.umd.EDU> > Nobody was quite sure how mmap `ought' to work, and it never got > implemented.... > >.... in BSD. So those vendors who needed it, SUN and Sequent, implemented >it *differently*. Encore probably has another variation. ^^^^^^ First, my credentials: I'm a kernel hacker for Encore's Umax4.2 kernel. Now: If you're running UmaxV on a Multimax, you get System V shared memory semantics (since UmaxV is SVR3 compatible) If you're currently running Umax4.2, you get a very simple shared memory semantic which basically says, "Share this piece of my address space with any processes that I fork off". This shared memory does not survive across an exec, so basically any programs that try to make use of shared memory have to be monolithic. Seems crude and ugly, I know, but you'd be surprised how many programs can be parallelized very nicely using just this semantic. For our next major release of Umax4.X, we plan to support System V shared memory semantics. "Why?", I hear the BSD fans cry. Simply because for good or for ill System V is the ONLY UNIX shared-memory semantic out there that more than three people seem to agree upon. If `mmap' ever gets fully defined and implemented in the future and there seems to be an audience for it, then we might add support for it. Currently, though, we don't have the resources to go defining standards that nobody's going to want to use 8-). Trivia bowl time (related to another comp.unix.wizards topic). Some have argued that a great way to access shared-memory regions is through the filesystem namespace. Well, there is at least one operating system out there that does just that. Which OS is that? [sound of Jeopardy theme music...] VMS. They're called "global segments". Of course, VMS has the interesting "feature" of not just treating the filesystem object as a handle for the shared memory region, but also using it to reference a FILE that the region is paged from/to. Whether this is good or bad is a mixed bag. Once the last person detaches from the global segment, voila` -- you have a regular file containing the data that was in the global segment (when the file is actually in use for paging it's inaccessible as a regular file). This can be seen as either a benefit or a security risk. One of the benefits is that once the last process detaches from the region it remains with its data intact to be attached by another process, consuming only filesystem space in the interim. Hell, you could even survive system shutdowns that way! (clean shutdowns only; no telling what state the file will be in after a crash!) > System V shared memory is wrong. > Perhaps. But right now it's the only game in town, unless you're rolling your own (how's THAT for well-mixed metaphors 8-) ) +----------------+ Jim Paradis linus--+ +--+-------------+ | Encore Computer Corp. necntc--| | | E N C O R E | | 257 Cedar Hill St. ihnp4--+-encore!paradis | +-------------+--+ Marlboro MA 01752 decvax--| +----------------+ (617) 460-0500 talcott--+ Well, what's the pleasure in THAT??!!
riedl@cs.purdue.EDU (John T Riedl) (03/02/88)
Another feature of the choice to make semaphores/FIFOs/shared memory
segments different from file descriptors is that select(3) presumably
won't work with them. How does one check the condition "is data ready
on my queue or on my UDP port?"
Thanks,
--
John Riedl
{ucbvax,decvax,hplabs}!purdue!riedl -or- riedl@mordred.cs.purdue.edurichard@aiva.ed.ac.uk (Richard Tobin) (03/03/88)
In article <14020007@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes: >There should be a way to cause private shared memory segments >to vanish upon termination of a process or process group. Is this not when happens when you do shmctl(shmid, IPC_RMID, 0); ? I know it's not what the documentation says, but it's what it seems to do (at least in Sun's implementation of system V shared memory). -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
rk9005@cca.ucsf.edu (Roland McGrath) (03/03/88)
["Shared Memory in BSD4.3 is lacking?"] - chris@trantor.umd.edu (Chris Torek): } >I agree that the user interface is annoying, } } (It feels like something IBM might have invented.) Oh, come now! Even big brother AT&T doesn't deserve such grevious insults! -- Roland McGrath ARPA: roland@rtsg.lbl.gov roland@lbl-rtsg.arpa UUCP: ...!ucbvax!lbl-rtsg.arpa!roland
ford@kenobi.UUCP (Mike Ditto) (03/04/88)
Posting-Front-End: GNU Emacs 18.41.10 of Fri Oct 2 1987 on kenobi (usg-unix-v) In article <3371@medusa.cs.purdue.edu> riedl@cs.purdue.EDU (John T Riedl) writes: > Another feature of the choice to make semaphores/FIFOs/shared memory > segments different from file descriptors is that select(3) presumably > won't work with them. How does one check the condition "is data ready > on my queue or on my UDP port?" In exactly the way you would expect. How is the question "is data ready on my queue or on my UDP port?" different from "is data ready on my UDP port or on my other UDP port?" Select would make perfect sense with IPC "descriptors". A memory segment is just like a file, always ready for reading or writing. Message queues could respond to select just like sockets or pipes do. I don't know about semaphores, since I still haven't thought of what read() and write() should do to a semaphore. But it makes sense to be able to say "Sleep until a key is typed, or a message comes in on this queue, or that semaphore is cleared." Actually, select is another strong argument for having IPC descriptors. -=] Ford [=- "Well, he didn't know what to do, so (In Real Life: Mike Ditto) he decided to look at the government, ford%kenobi@crash.CTS.COM to see what they did, and scale it ...!sdcsvax!crash!kenobi!ford down and run his life that way." -- Laurie Anderson
wcs@ho95e.ATT.COM (Bill.Stewart.<ho95c>) (03/05/88)
In article <2368@umd5.umd.edu> chris@trantor.umd.edu (Chris Torek) writes: :>In article <2329@umd5.umd.edu> I wrote: :>:System V shared memory is wrong. (Now there is a good flammable :In article <2009@ho95e.ATT.COM> wcs@ho95e.UUCP :>Ok, I'll flame! What's wrong with System V shared memory? [various good responses from Chris, Mike Ditto, and others] Yeah, I agree IPC really should be attached to the file system, though I'm not sure whether it should look like a regular file or like some variant on the "pipe" special file type or a character-special. Some of the "reasonable" implementations start to look appallingly like mmap(). :>I agree that the user interface is annoying, :(It feels like something IBM might have invented.) Ouch, that's getting nasty :-)! :Additionally, the total number of shared pages allowed is, I believe, :compiled into the kernel. It's at least configurable. On some architectures, with ancient or bizarre MMUs, it's tough to be flexible. :Finally, there is, it seems, no way to have sbrk and shm* :co-operate. This doesn't bother me much - sbrk is inherently dealing with a different memory space. But it *would* be nice to have malloc() able to use shm. :The future BSD shared memory will cure all of these :defects, or at least we think so.... If you do it right, it may be possible to write a System-V IPC emulation library, to preserve existing software. Bill Stewart, ho95c!wcs -- :[what *are* all those numbers in your name, anyway? :-) ] :(46323-Bill.Stewart,2G218,x0705,) writes: ^department ^room ^phone-extension The standard AT&T Bell Labs Comp. Center format for the gcos field is 11111-name(ABC123)1111 ^dept ^acct# ^printerbin The news software drops the account and printer bin. My department has extended the format a bit; we long ago added ",room-number,phone-extension" (see 4.1BSD passwd(5) - but we don't expand E and C to Evans and Cory); our current administrators have recently added a <home-machine> field. -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
rbj@icst-cmr.arpa (Root Boy Jim) (03/05/88)
Another feature of the choice to make semaphores/FIFOs/shared memory
segments different from file descriptors is that select(3) presumably
won't work with them. How does one check the condition "is data ready
on my queue or on my UDP port?"
Which brings a question to my mind. Are there any restrictions on the
things the selected fd's are attached to? I tend to think of using
select on tty's or sockets (pipes), but do they work on regular files
as well? What if the file pointer is at EOF? And then what if someone
appends to the file? What about tape drives?
Thanks,
--
John Riedl
{ucbvax,decvax,hplabs}!purdue!riedl -or- riedl@mordred.cs.purdue.edu
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
I'm mentally OVERDRAWN! What's that SIGNPOST up ahead?
Where's ROD STERLING when you really need him?rbj@icst-cmr.arpa (Root Boy Jim) (03/05/88)
In article <12033@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: > From: Chris Torek <chris@trantor.umd.EDU> > Nobody was quite sure how mmap `ought' to work, and it never got > implemented.... > >.... in BSD. So those vendors who needed it, SUN and Sequent, implemented >it *differently*. Encore probably has another variation. ^^^^^^ If you're currently running Umax4.2, you get a very simple shared memory semantic which basically says, "Share this piece of my address space with any processes that I fork off". This shared memory does not survive across an exec, so basically any programs that try to make use of shared memory have to be monolithic. Seems crude and ugly, I know, but you'd be surprised how many programs can be parallelized very nicely using just this semantic. Great! Somebody actually implemented my idea! I hadn't thought about sharing only *some* of the data space, my idea was to share it all. Trivia bowl time (related to another comp.unix.wizards topic). Some have argued that a great way to access shared-memory regions is through the filesystem namespace. Well, there is at least one operating system out there that does just that. Which OS is that? [sound of Jeopardy theme music...] VMS. They're called "global segments". Of course, VMS has the interesting "feature" of not just treating the filesystem object as a handle for the shared memory region, but also using it to reference a FILE that the region is paged from/to. Whether this is good or bad is a mixed bag. Once the last person detaches from the global segment, voila` -- you have a regular file containing the data that was in the global segment (when the file is actually in use for paging it's inaccessible as a regular file). This can be seen as either a benefit or a security risk. One of the benefits is that once the last process detaches from the region it remains with its data intact to be attached by another process, consuming only filesystem space in the interim. Hell, you could even survive system shutdowns that way! (clean shutdowns only; no telling what state the file will be in after a crash!) [sound of Twilight Zone (Grateful Dead!) music...] Your friends at Sequent do the same thing. However, what they are really doing is marking certain pieces of the buffer cache resident and non-reclaimable, then mapping them into the processes space. +----------------+ Jim Paradis linus--+ +--+-------------+ | Encore Computer Corp. necntc--| | | E N C O R E | | 257 Cedar Hill St. ihnp4--+-encore!paradis | +-------------+--+ Marlboro MA 01752 decvax--| +----------------+ (617) 460-0500 talcott--+ Well, what's the pleasure in THAT??!! (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 All of a sudden, I want to THROW OVER my promising ACTING CAREER, grow a LONG BLACK BEARD and wear a BASEBALL HAT!! ... Although I don't know WHY!!
rbj@icst-cmr.arpa (Root Boy Jim) (03/05/88)
["Shared Memory in BSD4.3 is lacking?"] chris@trantor.umd.edu (Chris Torek): } >I agree that the user interface is annoying, } } (It feels like something IBM might have invented.) Oh, come now! Even big brother AT&T doesn't deserve such grevious insults! That's Big *Mother*. You and I work for Big *Brother*. Roland McGrath ARPA: roland@rtsg.lbl.gov roland@lbl-rtsg.arpa UUCP: ...!ucbvax!lbl-rtsg.arpa!roland (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 Tex SEX! The HOME of WHEELS! The dripping of COFFEE!! Take me to Minnesota but don't EMBARRASS me!!
allbery@ncoast.UUCP (Brandon Allbery) (03/06/88)
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
barmar@think.COM (Barry Margolin) (03/06/88)
In article <12137@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: > Trivia bowl time (related to another comp.unix.wizards topic). Some have > argued that a great way to access shared-memory regions is through the > filesystem namespace. Well, there is at least one operating system out > there that does just that. Which OS is that? > [sound of Jeopardy theme music...] Multics, for at least a decade longer than VMS. In fact, the only way to access files on Multics is to map them onto memory segments. And if two processes happen to map the same file they get shared memory. Shared binaries are also a natural result of this, and coupled with dynamic linking you also get shared libraries. In a couple of decades Unix will finish living up to its progenitor's expectations. I believe TOPS-20 also allows processes to map files into their address space and get shared memory that way. Barry Margolin Thinking Machines Corp. barmar@think.com uunet!think!barmar
rbk@sequent.UUCP (Bob Beck) (03/08/88)
In article <12137@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: > >Your friends at Sequent do the same thing. However, what they are >really doing is marking certain pieces of the buffer cache resident >and non-reclaimable, then mapping them into the processes space. Not true. mmap() works in Dynix by mapping portions of files into address spaces on page boundaries. The file acts as a paging source and store for the data; the pages of the file are demand loaded directly into user addressible memory, no buffer cache involved. The buffer cache does remain coherent, however, so read/write system calls see the latest data. Bob Beck Sequent Computer Systems 15450 SW Koll Parkway Beaverton, Oregon 97006 ...{tektronix,ogcvax}!sequent!rbk (503)626-5700
dkc@hotlr.ATT (Dave Cornutt) (03/08/88)
In article <17584@think.UUCP>, barmar@think.COM (Barry Margolin) writes: > In article <12137@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: > > Trivia bowl time (related to another comp.unix.wizards topic). Some have > > argued that a great way to access shared-memory regions is through the > > filesystem namespace. Well, there is at least one operating system out > > there that does just that. Which OS is that? > > [sound of Jeopardy theme music...] VMS, of course. There's just one small problem...to create a global segment, you need a *privilege*. Can you say INSTALL? I knew you could. (If you're a VMS admin, you probably get lots of practice.) -- Dave Cornutt, AT&T Bell Labs (rm 4A406), Holmdel, NJ (Note new address!) UUCP:{ihnp4,allegra,cbosgd}!hotly!dkc (path stolen from Shelley) "The opinions expressed herein are not necessarily my employer's, not necessarily mine, and probably not necessary"
rbj@icst-cmr.arpa (Root Boy Jim) (03/16/88)
From: Bob Beck <rbk@sequent.uucp> In article <12137@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: > >Your friends at Sequent do the same thing. However, what they are >really doing is marking certain pieces of the buffer cache resident >and non-reclaimable, then mapping them into the processes space. Not true. mmap() works in Dynix by mapping portions of files into address spaces on page boundaries. The file acts as a paging source and store for the data; the pages of the file are demand loaded directly into user addressible memory, no buffer cache involved. The buffer cache does remain coherent, however, so read/write system calls see the latest data. I am speaking loosely. Your implementation may not actually be as I have suggested, but it *could* be implemented that way. And of course you'd have to align everything on page boundarys to make it work. Once upon a time (and possibly now) I believe the buffer structures were prefixed with a header, so their addresses didn't align. This could be fixed by stuffing a pointer to the real page aligned buffer in the header. Bob Beck Sequent Computer Systems 15450 SW Koll Parkway Beaverton, Oregon 97006 ...{tektronix,ogcvax}!sequent!rbk (503)626-5700 (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688
mangler@cit-vax.Caltech.Edu (Don Speck) (03/20/88)
In article <12136@brl-adm.ARPA>, rbj@icst-cmr.arpa (Root Boy Jim) writes: > I tend to think of using > select on tty's or sockets (pipes), but do they work on regular files > as well? What if the file pointer is at EOF? And then what if someone > appends to the file? What about tape drives? On disk and tape, select() returns success immediately. What ought to happen instead is that select() on a disk file should pause until the buffer cache contains the block that would be needed to satisfy a read at the current file pointer. This may involve queuing a block I/O request, or just waiting for a read-ahead to finish. Making this work properly at EOF would certainly make "tail -f" more efficient! In the same vein, select() on a raw disk would initiate a seek, allowing a certain amount of asynchronous I/O. Similarly, select() on a tape drive ought to pause until the tape is positioned for I/O and not moving (and certainly not rewinding). Don Speck speck@vlsi.caltech.edu {amdahl,ames!elroy}!cit-vax!speck