Path: utzoo!attcan!uunet!husc6!frooz!cfa.HARVARD.EDU
From: wyatt@cfa.HARVARD.EDU (Bill Wyatt,OIR)
Newsgroups: comp.unix.internals
Subject: Re: shmat() & shmdt() questions.
Message-ID: <458@cfa.HARVARD.EDU>
Date: 20 Sep 90 14:34:09 GMT
References: <1990Sep15.130415.28456@virtech.uucp>
Sender: news@cfa.HARVARD.EDU
Lines: 31

> 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