Path: utzoo!attcan!uunet!virtech!cpcahil From: cpcahil@virtech.uucp (Conor P. Cahill) Newsgroups: comp.unix.internals Subject: Re: shmat() & shmdt() questions. Message-ID: <1990Sep15.130415.28456@virtech.uucp> Date: 15 Sep 90 13:04:15 GMT References: <24482@adm.BRL.MIL> <1990Sep13.121318.24305@virtech.uucp> Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill) Organization: Virtual Technologies Inc., Sterling VA Lines: 32 In article 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