TAYBENGH%NUSDISCS.BITNET@cunyvm.cuny.edu (09/13/90)
I have 3 questions regarding usage of shared memory:
1) can a child process inherit shmid from parent? i.e. does the shmid
valid in the following program segment?
shmid = shmget(..);
if (fork() != 0)
{ /* parent process */
parent_shm = shmat(shmid, (char *)0, 0);
/* do sth on parent_shm */
.....
}
else
{ /* child process */
child_shm = shmat(shmid, (char *)0, 0);
/* do sth on child_shm */
.....
}
2) can a child inherit the virtual address return by shmat()?
for eg:
shmid = shmget(..);
addr = shmat(.shmid, (char *)0, 0);
if (fork() != 0)
{
/* do sth on addr */
...
}
else
{
/* can child sth on addr ??? */
.....
}
3) if a process quit without shmdt() the shared memory it attached
to, will the OS detect and decrement the shm_nattch in structure sgmid_ds?
Thanks a lot for the help.
- Beng Hang (email: taybengh@nusdiscs)gt0178a@prism.gatech.EDU (BURNS,JIM) (09/13/90)
in article <24482@adm.BRL.MIL>, TAYBENGH%NUSDISCS.BITNET@cunyvm.cuny.edu says: > I have 3 questions regarding usage of shared memory: > 1) can a child process inherit shmid from parent? i.e. does the shmid > valid in the following program segment? Yes. Adapted from the HP 9000/800 HP-UX Real Time Programmers Manual: On shmget(2): "If your communication application consists of related processes, you should call shmget(2) with the key parameter set to IPC_PRIVATE in the following way: myshmid = shmget (IPC_PRIVATE, 4096, 0600); "This call to shmget(2) returns a unique shared memory identifier (shmid), which is saved in the variable myshmid, for the newly created shared memory segment. The size of the segment is 4096 bytes and its access permissions are read and write permission for the owner. This call to shmget(2) should appear in your program sometime before the fork() statement so that the child processes in your communication application will inherit myshmid. ^^^^^^^^^^^^^^^^^^^^^ > 2) can a child inherit the virtual address return by shmat()? > for eg: > shmid = shmget(..); > addr = shmat(.shmid, (char *)0, 0); This is dangerous. The proper method is for the child to also do a shmat(). On *some* OS's, the address returned by shmat() is the same in all processes, but virtual OS's, (or even ones that play w/ the MMU) might return different addresses, and the same address might mean different things to different procs. > 3) if a process quit without shmdt() the shared memory it attached > to, will the OS detect and decrement the shm_nattch in structure sgmid_ds? All IPC resources should be properly cleaned up by the OS by default. However, the shm segment itself still exists, and should be removed with shmctl(2) or ipcrm(1). -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
cpcahil@virtech.uucp (Conor P. Cahill) (09/13/90)
In article <24482@adm.BRL.MIL> TAYBENGH%NUSDISCS.BITNET@cunyvm.cuny.edu writes: > > 1) can a child process inherit shmid from parent? i.e. does the shmid >valid in the following program segment? Yes. In fact this is the only way to use private shared memory segments. The child will also inherit an attached segment, so you could just attach it once before you fork. Once you have a shmid, you can pass that around through any means (pipe, file, etc) and any other process can use that id to gail access to the shared memory segment (as long as they have the correct permissions). I once used this mechanism for a daemon that read data packets from a serial port and was to forward them to any one of several other daemons. The solution I used was to encode the msgid in the data packet and use it in the daemon to send the packet to the appropriate daemon. > 2) can a child inherit the virtual address return by shmat()? Yes, see above. > 3) if a process quit without shmdt() the shared memory it attached >to, will the OS detect and decrement the shm_nattch in structure sgmid_ds? Yes. And if this segment is designed to be a temporary segment that is supposed to be removed when the last program is done with it, you can run shmctl(... IPC_RM) once you have attached to it and then it will be removed when the total number of attached processes drops to zero. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
cpcahil@virtech.uucp (Conor P. Cahill) (09/13/90)
In article <13612@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (BURNS,JIM) writes: > >> 2) can a child inherit the virtual address return by shmat()? >> for eg: >> shmid = shmget(..); >> addr = shmat(.shmid, (char *)0, 0); > >This is dangerous. The proper method is for the child to also do a >shmat(). On *some* OS's, the address returned by shmat() is the same in >all processes, but virtual OS's, (or even ones that play w/ the MMU) might >return different addresses, and the same address might mean different >things to different procs. This isn't dangerous. Once the shared memory segment is attached it is *supposed* to remain with the process (and therefore can move) even through forks. (since we are talking about a fork, we must be talking about the same kind of process and therefore there shouldn't be any difference between the two process (other than the return of fork) unless that vendor has broken something). -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
gt0178a@prism.gatech.EDU (BURNS,JIM) (09/14/90)
in article <1990Sep13.121704.24384@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) says: > This isn't dangerous. Once the shared memory segment is attached it > is *supposed* to remain with the process (and therefore can move) even > through forks. (since we are talking about a fork, we must be talking > about the same kind of process and therefore there shouldn't be any > difference between the two process (other than the return of fork) unless > that vendor has broken something). Oops! I was thinking of a previous discussion involving *un*related processes. To quote TFM: Fork causes the creation of a new process. The new process (child process) is an exact copy of the calling process (parent process). This means that the child process inherits the following attributes from the parent process: [...] all attached shared memory segments (see shmop(2)) ^^^^^^^^^^^^ [...] Hewlett-Packard Company - 1 - HP-UX Release 7.0: Sept 1989 -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
jay@retix.retix.retix.com (Jay Logue) (09/15/90)
In article <1990Sep13.121318.24305@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes: >In article <24482@adm.BRL.MIL> TAYBENGH%NUSDISCS.BITNET@cunyvm.cuny.edu writes: > > [ ... ] > >> 3) if a process quit without shmdt() the shared memory it attached >>to, will the OS detect and decrement the shm_nattch in structure sgmid_ds? > >Yes. And if this segment is designed to be a temporary segment that is >supposed to be removed when the last program is done with it, you can >run shmctl(... IPC_RM) once you have attached to it and then it will ^^^^^^ >be removed when the total number of attached processes drops to zero. What is IPC_RM? It is not mentioned in my AT&T System V/386 book nor is it present in any of the header files on my SCO Unix 386 system. The closest shmctl command value listed in the AT&T book is IPC_RMID, which is used to remove the shmid along with the shared memory segment. This sounds to me like an added feature of your Un*x. The ability to have a "temporary" shared memory segment would be great but I don't think standard System V R3 provides this. Jay Logue =============================================================================== Retix USMail: 2644 30th Street, Santa Monica, CA 90405-3009 U.S.A Tel: (213) 399-1611 Fax: (213) 458-2685 Telex: 4944307 E-mail: jay@retix.com X.400: C=US;ADMD=TELEMAIL;PRMD=RETIX;O=OSI ONE;S=LOGUE;G=JAY ===============================================================================
cpcahil@virtech.uucp (Conor P. Cahill) (09/15/90)
In article <JAY.90Sep14131954@retix.retix.retix.com> jay@retix.retix.retix.com (Jay Logue) writes: >In article <1990Sep13.121318.24305@virtech.uucp>, cpcahil@virtech.uucp >(Conor P. Cahill) writes: >>Yes. And if this segment is designed to be a temporary segment that is >>supposed to be removed when the last program is done with it, you can >>run shmctl(... IPC_RM) once you have attached to it and then it will >>be removed when the total number of attached processes drops to zero. > >What is IPC_RM? It is not mentioned in my AT&T System V/386 book nor >is it present in any of the header files on my SCO Unix 386 system. >The closest shmctl command value listed in the AT&T book is IPC_RMID, >which is used to remove the shmid along with the shared memory >segment. I meant IPC_RMID. I don't know where that functionality (that the shared memory segment will be marked for deletion, but not deleted until the last reference (attachment) is removed) is documented, but it does work that way. >This sounds to me like an added feature of your Un*x. The ability to >have a "temporary" shared memory segment would be great but I don't >think standard System V R3 provides this. It is part of standard System V R2 and all releases forward. Every machine that I have seen that has shared memory (the system V kind) has this functionality. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
gt0178a@prism.gatech.EDU (BURNS,JIM) (09/16/90)
in article <1990Sep15.130415.28456@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) says: > I meant IPC_RMID. I don't know where that functionality (that the shared > memory segment will be marked for deletion, but not deleted until the > last reference (attachment) is removed) is documented, but it does > work that way. It's documented in (at least) the HP 9000/800 HP-UX Real Time Programmers Manual: "A process can detach the shared memory segment from its data space by calling shmdt(). The process should detach after it has finished accessing the shared memory segment. However, it is not necessary to explicitly detach the segment with shmdt() because the system will detach the segment as part of the process's exit code. "If a process performs a shmdt() and a shmctl(2) with IPC_RMID, it is not necessary to call shmdt() first. If shmctl(2) with IPC_RMID is called first, the system will not remove the shmid, segment or data structure until the last attached process has detached. However, no additional processes can attach to the segment." ex - "shmctl(myshmid, IPC_RMID, 0);", altho' actually shmctl(2) does have an int return code. I've also seen it in the SunOS man pages, altho' I have seen it omitted in other system's man pages. > In article <JAY.90Sep14131954@retix.retix.retix.com> jay@retix.retix.retix.com (Jay Logue) writes: >>This sounds to me like an added feature of your Un*x. The ability to >>have a "temporary" shared memory segment would be great but I don't >>think standard System V R3 provides this. I don't it's that there are "temporary" shm segs (there aren't) so much as its *use* is temporary. You have to explicitly remove a shm seg as above. -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
wyatt@cfa.HARVARD.EDU (Bill Wyatt,OIR) (09/17/90)
>> 1) can a child process inherit shmid from parent? i.e. does the shmid >> valid in the following program segment? > Yes. Adapted from the HP 9000/800 HP-UX Real Time Programmers Manual: [... example with use of IPC_PRIVATE...] IPC_PRIVATE is useful, but is not needed for this example (see my second point below about fork). In the example given, the idea is to keep the memory shared *only* between the parent and child, but it doesn't have anything to do with making the same ID access the same shared segment. >> 2) can a child inherit the virtual address return by shmat()? [...] > This is dangerous. The proper method is for the child to also do a > shmat(). On *some* OS's, the address returned by shmat() is the same in > all processes, but virtual OS's, (or even ones that play w/ the MMU) might > return different addresses, and the same address might mean different > things to different procs. [...] No, it shouldn't be dangerous. By the definition of fork(), the two processes are identical except in some well-defined ways. The addresses of all objects are identical. >> 3) if a process quit without shmdt() the shared memory it attached >> to, will the OS detect and decrement the shm_nattch in structure sgmid_ds? > All IPC resources should be properly cleaned up by the OS by default. > However, the shm segment itself still exists, and should be removed with > shmctl(2) or ipcrm(1). Yes. One thing that bugs me is that there's apparently no way (at least under Ultrix) to mark a segment for deletion when its reference count goes to zero. As with semaphores and message queues, the useful file system semantics were not implemented, making these a pain to control. They are very useful, though, so I continue to use them. Bill Wyatt, Smithsonian Astrophysical Observatory (Cambridge, MA, USA) UUCP : {husc6,cmcl2,mit-eddie}!harvard!cfa!wyatt Internet: wyatt@cfa.harvard.edu SPAN: cfa::wyatt BITNET: wyatt@cfa
josef@nixpbe.UUCP (Moellers) (09/17/90)
In <24482@adm.BRL.MIL> TAYBENGH%NUSDISCS.BITNET@cunyvm.cuny.edu writes: > I have 3 questions regarding usage of shared memory: > 1) can a child process inherit shmid from parent? i.e. does the shmid >valid in the following program segment? [example deleted] - the manual sais that children inherit any ATTACHED shared memory segments (SMSs) - the shmid is just an id which is bound to the SMS, so it should make no difference whether the parent hands the shmid to it's child or the child gets the shmid itself. > 2) can a child inherit the virtual address return by shmat()? [code example deleted] see my first remark on question 1. > 3) if a process quit without shmdt() the shared memory it attached >to, will the OS detect and decrement the shm_nattch in structure sgmid_ds? Yes (if the OS is programmed properly B-{) > Thanks a lot for the help. Hope it was any. -- | Josef Moellers | c/o Nixdorf Computer AG | | USA: mollers.pad@nixdorf.com | Abt. PXD-S14 | | !USA: mollers.pad@nixdorf.de | Heinz-Nixdorf-Ring | | Phone: (+49) 5251 104662 | D-4790 Paderborn |
cpcahil@virtech.uucp (Conor P. Cahill) (09/17/90)
In article <452@cfa.HARVARD.EDU> wyatt@cfa.HARVARD.EDU (Bill Wyatt,OIR) writes: > >Yes. One thing that bugs me is that there's apparently no way (at >least under Ultrix) to mark a segment for deletion when its reference >count goes to zero. As with semaphores and message queues, the useful >file system semantics were not implemented, making these a pain to >control. They are very useful, though, so I continue to use them. Have you tried using shmctl(.. IPC_RMID..) to do this? The feature of not deleting the item until count goes to zero is usually not documented for shared memory segments (although it is not only not-documented for messages & semaphores, it doesn't work for them). Try it, you may be pleasantly suprised. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
jdarcy@encore.com (Mostly Harmless) (09/17/90)
wyatt@cfa.HARVARD.EDU (Bill Wyatt,OIR) writes: >Yes. One thing that bugs me is that there's apparently no way (at >least under Ultrix) to mark a segment for deletion when its reference >count goes to zero. As with semaphores and message queues, the useful >file system semantics were not implemented, making these a pain to >control. They are very useful, though, so I continue to use them. UMAX V, Encore's version of UNIX V.3, has exactly this feature. From the man page: As a non-standard extension, if (shmflg & IPC_DESTROY) is "true", the shared memory region is automatically destroyed when the reference count of attached processes shm_nattach is reduced to zero. This often avoids adding code to keep track of currently attached shared memory regions and removing them in otherwise unnecessary signal handlers on exit. This is an Encore Computer Corporation extension; it is not in the System V Interface Definition (SVID). -- Jeff d'Arcy, Generic Software Engineer - jdarcy@encore.com Nothing was ever achieved by accepting reality
gt0178a@prism.gatech.EDU (BURNS,JIM) (09/18/90)
in article <452@cfa.HARVARD.EDU>, wyatt@cfa.HARVARD.EDU (Bill Wyatt,OIR) says: > IPC_PRIVATE is useful, but is not needed for this example (see my second Granted, he could have just as easily used the more general call: myshmid = shmget (some-made-up-not-in-use-int-id, 4096, IPC_CREAT|600); but that paragraph answered his question about inheritance. > point below about fork). In the example given, the idea is to keep the > memory shared *only* between the parent and child, but it doesn't have I assume you are talking about MY example, not his. > anything to do with making the same ID access the same shared segment. Since the id is inherited, it IS the same id. -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
gt0178a@prism.gatech.EDU (BURNS,JIM) (09/18/90)
in article <13782@hydra.gatech.EDU>, I write: > myshmid = shmget (some-made-up-not-in-use-int-id, 4096, IPC_CREAT|600); ^^^ I suppose that should actually be 'long', as in 'key_t'. I actually normally use an ascii representation of a 4-char string (assuming key_t=long). E.g. - if I want the key to be 'phs1', I use '0x70687331'. -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
dave@dptechno.UUCP (Dave Lee) (09/20/90)
In article <13783@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (BURNS,JIM) writes: >in article <13782@hydra.gatech.EDU>, I write: >> myshmid = shmget (some-made-up-not-in-use-int-id, 4096, IPC_CREAT|600); > ^^^ > >I suppose that should actually be 'long', as in 'key_t'. I actually >normally use an ascii representation of a 4-char string (assuming >key_t=long). E.g. - if I want the key to be 'phs1', I use '0x70687331'. And just how is one supposed to know what is "not-in-use" ?, unless ofcourse, you just happen to be in controll of all the sources to all programs that may ever run on your machine. If everyone would use ftok(path,id) (see stdipc(3C)) as recomended in the FM, (and then document the path and id used), then selecting a key would have a lot less chance of colliding with other program uses. Unless you really want a private key, then use IPC_PRIVATE. IMHO of course. -- Dave Lee uunet!dptechno!dave
wyatt@cfa.HARVARD.EDU (Bill Wyatt,OIR) (09/20/90)
> I meant IPC_RMID. I don't know where that functionality (that the shared > memory segment will be marked for deletion, but not deleted until the > last reference (attachment) is removed) is documented, but it does > work that way. <<This sounds to me like an added feature of your Un*x. The ability to <<have a "temporary" shared memory segment would be great but I don't <<think standard System V R3 provides this. > It is part of standard System V R2 and all releases forward. Every > machine that I have seen that has shared memory (the system V kind) > has this functionality. It also exists under Ultrix [234].x and SunOS 4.0.3. IPC_RMID (esp. in combination with IPC_PRIVATE) is useful when a process creates a segment and forks a child. However, it doesn't do what I sometimes want, which is to mark a segment for deletion after the last process attaching it exits BUT that is still attachable by new processes until then. That way, a program could create a segment and immediately mark it for non-permanent use, yet not have any idea how many other processes might access that segment. That functionality doesn't exist for files, either (by analogy, unlink() and directory entries instead of shmctl(,IPC_RMID,) and segment ID's), so perhaps I'm being unreasonable. Bill Wyatt, Smithsonian Astrophysical Observatory (Cambridge, MA, USA) UUCP : {husc6,cmcl2,mit-eddie}!harvard!cfa!wyatt Internet: wyatt@cfa.harvard.edu SPAN: cfa::wyatt BITNET: wyatt@cfa
gt0178a@prism.gatech.EDU (BURNS,JIM) (09/21/90)
in article <583@dptechno.UUCP>, dave@dptechno.UUCP (Dave Lee) says: >>key_t=long). E.g. - if I want the key to be 'phs1', I use '0x70687331'. > And just how is one supposed to know what is "not-in-use" ?, unless ofcourse, > you just happen to be in controll of all the sources to all programs that > may ever run on your machine. > If everyone would use ftok(path,id) (see stdipc(3C)) as recomended in the FM, In our case, we are developing a system for the gov't, so we DO control the sources. Obviously, in a more open environment, ftok(3) would be better. I just happen to prefer something that has *some* semantic content when I read an ipcs(1) display, even if it is an ascii representation of a string, than something chosen by a computer. (In this case, 'phs1' is short for 'phase 1'.) It is also what the HP-UX Fortran compiler's directives require you to do when you create a shm seg, so it is a design decision the vendor prefers too. -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (09/22/90)
As quoted from <583@dptechno.UUCP> by dave@dptechno.UUCP (Dave Lee): +--------------- | In article <13783@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (BURNS,JIM) writes: | >in article <13782@hydra.gatech.EDU>, I write: | >> myshmid = shmget (some-made-up-not-in-use-int-id, 4096, IPC_CREAT|600); | > ^^^ | >I suppose that should actually be 'long', as in 'key_t'. I actually | >normally use an ascii representation of a 4-char string (assuming | >key_t=long). E.g. - if I want the key to be 'phs1', I use '0x70687331'. | | And just how is one supposed to know what is "not-in-use" ?, unless ofcourse, | you just happen to be in controll of all the sources to all programs that | may ever run on your machine. | | If everyone would use ftok(path,id) (see stdipc(3C)) as recomended in the FM, | (and then document the path and id used), then selecting a key would have a | lot less chance of colliding with other program uses. Unless you really | want a private key, then use IPC_PRIVATE. +--------------- If shared memory were in the standard namespace, this wouldn't be a problem. Yes, this is a change of tune for me. But I was hoping that AT&T would eventually integrate the two namespaces into a single one. From the UNIX/WORLD description, it looks like they have... research, at least. (See the article on Plan 9.) I wonder how long before the commercial side picks up on that concept? ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
cpcahil@virtech.uucp (Conor P. Cahill) (09/23/90)
In article <1990Sep22.163631.23688@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/KT) writes: >Yes, this is a change of tune for me. But I was hoping that AT&T would >eventually integrate the two namespaces into a single one. From the >UNIX/WORLD description, it looks like they have... research, at least. (See >the article on Plan 9.) I wonder how long before the commercial side picks up >on that concept? Actually they have. System V.4 provides memory mapped files and with the way virtual memory is managed, a memory mapped file that is being accessed will attain about the same performance as shared memory, plus you use the file system to access the file. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
mikep@dirty.csc.ti.com (Michael A. Petonic) (09/26/90)
In article <1990Sep22.163631.23688@NCoast.ORG> allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) writes: >If shared memory were in the standard namespace, this wouldn't be a problem. > >Yes, this is a change of tune for me. But I was hoping that AT&T would >eventually integrate the two namespaces into a single one. From the >UNIX/WORLD description, it looks like they have... research, at least. (See >the article on Plan 9.) I wonder how long before the commercial side picks up >on that concept? Three Chears for Brandon! It seems to be that as soon as AT&T Information Systems gets on the ball (perennially chasing Bell Labs and the rest of the industry), we'll have saner IPC mechanisms in System V. Hell, even Xenix has shared memory identifiers in the filesystem namespace. Ack! -MikeP
peter@ficc.ferranti.com (Peter da Silva) (09/27/90)
In article <583@dptechno.UUCP> dave@dptechno.UUCP (Dave Lee) writes: > If everyone would use ftok(path,id) (see stdipc(3C)) as recomended in the FM, Minor flame: if the people who wrote the FM had thought about things a little earlier when they wrote the FS there would be a lot fewer FK like this. The shared memory objects should have been in the file system right from the start. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
peter@ficc.ferranti.com (Peter da Silva) (09/27/90)
In article <1990Sep22.215535.16776@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: > Actually they have. System V.4 provides memory mapped files and with the V.4 does this, V.4 does that... and so on. I have a question. In V.4 have they finally got all those bloody stupid commands to use perror? I'm getting really sick of "cat: can't open <filename>". -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
guy@auspex.auspex.com (Guy Harris) (09/30/90)
>Hell, even Xenix has shared memory identifiers in the filesystem >namespace. Ack! As has already been noted in this discussion, so does S5R4. See "mmap(2)".