logan@vsedev.VSE.COM (James Logan III) (06/01/88)
I am unable to find any documentations at all on the IPC_PRIVATE key that can be passed to the shmget() system call. IPC_PRIVATE is defined in /usr/include/sys/ipc.h and has only one ambiguous comment, "private key". Does this mean that the region that I attach will be accessable only to my process? If so, what is the point to bothering the operating system for shared memory when the malloc() function yields the same results? The reason I ask is that I would like to share memory between two processes -- one parent and one child. This program will be run by more than one user at a time, therefore I cannot just hard-code some key in the program. The only way that I know to solve the problem is to call shmget() with the IPC_EXCL flag in a loop that tries keys from 1 to some number. (Where do I stop? How many keys are possible under SysV? 2^32?) If the IPC_PRIVATE flag can be used to set up a segment that is shared between a parent and a child process but is invisible to other user's processes, this would be a more simplistic solution but I don't know what UNIX's idea of private is in this case. If anyone has done anything like this or has any ideas, please let me know. -- -- ron@vsedev.vse.com (Ron Flax) uucp: ..!uunet!vsedev!ron inet: ron%vsedev.vse.com@uunet.uu.net
stevens@hsi.UUCP (Richard Stevens) (06/02/88)
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 <sys/types.h>. Its probably a long, so 32-bits is right. Richard Stevens Health Systems International, New Haven, CT { uunet | ihnp4 } ! hsi ! stevens
johnk@juniper.UUCP (John Knutson) (06/03/88)
In article <1120@vsedev.VSE.COM> logan@vsedev.VSE.COM (James Logan III) writes: >I am unable to find any documentations at all on the >IPC_PRIVATE key that can be passed to the shmget() >system call. try the unix system V programmer's guide. >IPC_PRIVATE is defined in /usr/include/sys/ipc.h and >has only one ambiguous comment, "private key". Does >this mean that the region that I attach will be >accessable only to my process? If so, what is the >point to bothering the operating system for shared >memory when the malloc() function yields the same >results? the sysV programmer's guide says: " There is also a provision for specifying a key of value zero which is known as the private key (IPC_PRIVATE = 0); when specified, a new msqid is always returned with an associated message queue and data structure created for it unless a system tunable parameter would be exceeded. When the ipcs command is performed, for security reasons the KEY field for the msqid is all zeros." this doesn't explain much to me, but i hope it does you some good... (i'm using ipc messages to write a multi-person chat program) -- John Knutson ihnp4!ut-sally!ut-emx!juniper!johnk Build on the work of others -Unix System V Programmer's Guide Rack your brains on interpreting other people's code -Me Go psycho trying to understand the code you wrote just weeks ago -Me