Xref: utzoo comp.unix.questions:7363 comp.lang.c:10541 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!husc6!uwvax!dogie!uwmcsd1!marque!uunet!hsi!stevens From: stevens@hsi.UUCP (Richard Stevens) Newsgroups: comp.unix.questions,comp.lang.c Subject: Re: IPC_PRIVATE in shared memory Summary: shared memory Message-ID: <1008@hsi.UUCP> Date: 2 Jun 88 10:29:52 GMT References: <1120@vsedev.VSE.COM> Organization: Health Systems Intl., New Haven, CT Lines: 33 In article <1120@vsedev.VSE.COM>, logan@vsedev.VSE.COM (James Logan III) writes: > IPC_PRIVATE is defined in /usr/include/sys/ipc.h and > has only one ambiguous comment, "private key". When shmget() is passed a key of IPC_PRIVATE, it will allocate a new entry in its tables for a new region (assuming the kernel tables aren't full). The IPC_EXCL flag bit has no effect. Once you create an IPC channel with a PRIVATE key, no other process can call the shmget() system call and connect to that same IPC channel. You could pass the shmid values returned by shmget() to a child process. The fork(2) man page says that "all attached shared memory segments" are inherited by the child, so the parent could attach the segment, then the child can reference the segment through the address returned by shmat(). Note that shared memory as you propose between parent and child is really shared. To do an malloc(), and then a fork, will not provide the sharing, as the parent and child each have their own copy of the malloc'ed region in their own data space. > This program will be run by more than one user at a > time, therefore I cannot just hard-code some key in the > program. This is indeed what the IPC_PRIVATE key is intended for. > How many keys are possible under SysV? 2^32?) Look at key_t in. Its probably a long, so 32-bits is right. Richard Stevens Health Systems International, New Haven, CT { uunet | ihnp4 } ! hsi ! stevens