Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!umich!yale!husc6!frooz!cfa.HARVARD.EDU
From: wyatt@cfa.HARVARD.EDU (Bill Wyatt,OIR)
Newsgroups: comp.unix.internals
Subject: Re: shmat() & shmdt() questions.
Message-ID: <452@cfa.HARVARD.EDU>
Date: 17 Sep 90 02:24:50 GMT
References: <13612@hydra.gatech.EDU>
Sender: news@cfa.HARVARD.EDU
Lines: 42


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