shmat() & shmdt() questions.
BURNS,JIM
gt0178a at prism.gatech.EDU
Thu Sep 13 16:20:32 AEST 1990
in article <24482 at adm.BRL.MIL>, TAYBENGH%NUSDISCS.BITNET at 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 at prism.gatech.edu
More information about the Comp.unix.internals
mailing list