IPC_PRIVATE in shared memory

[Richard Stevens]

In article <1120 at vsedev.VSE.COM>, logan at 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 <sys/types.h>.  Its probably a long, so 32-bits is right.

	Richard Stevens
	Health Systems International, New Haven, CT
           { uunet | ihnp4 } ! hsi ! stevens