Xref: utzoo comp.unix.xenix:1702 comp.unix.microport:271 comp.unix.wizards:7140
Path: utzoo!mnetor!uunet!husc6!cmcl2!phri!manhat!mancol!samperi
From: samperi@mancol.UUCP (Dominick Samperi)
Newsgroups: comp.unix.xenix,comp.unix.microport,comp.unix.wizards
Subject: Re: IPC facilities (shared memory)
Message-ID: <351@mancol.UUCP>
Date: 17 Mar 88 06:18:51 GMT
References: <150@marob.MASA.COM> <9947@steinmetz.steinmetz.UUCP>
Reply-To: samperi@mancol.UUCP (Dominick Samperi)
Organization: Manhattan College
Lines: 22
Keywords: IPC, shared memory, semaphores
Summary: You are right, "officially", but...

>In article <150@marob.MASA.COM> samperi@marob.UUCP (Dominick Samperi) writes:
>| In article <9844@steinmetz.steinmetz.UUCP> Bill Davidsen writes:
>| >
>| >  SysV shared memory segments are inherited by the child, like any other
>| >open handle. If you open the segment and then do a fork, the child has
>| >access. If you fork and then open, the child will have to open, too.

I was told recently (by Amy Snader) that the SVID says that attached
shared memory segments are indeed inherited by forked children, so you
(and Xenix) are correct, "officially." It may also be true that it
is not necessary for forked child processes to reattach under System V/AT,
but I haven't checked this yet. On the other hand, I learned how to use
the IPC facilities on a 3B2/300, with very little documentation and no
examples, and I found by trial and error that the address that is returned
to a parent process by shmat() is not valid for its forked children; they
must explicitly attach the segment, using the shmid that was returned to the
parent by shmget().
-- 
Dominick Samperi, Manhattan College, NYC
    manhat!samperi@NYU.EDU           ihnp4!rutgers!nyu.edu!manhat!samperi
    philabs!cmcl2!manhat!samperi     ihnp4!rutgers!hombre!samperi
              (^ that's an ell)      uunet!swlabs!mancol!samperi