wsmith@cs.umn.edu (Warren Smith [Randy]) (06/03/91)
The keys used with the system V IPC mechanisms (msgget, shmget, semget) could collide if using software provided by different groups or vendors. The books+manuals I've seen don't address this problem. How does one go about selecting keys when the software may need to run on systems where other products are using the IPC mechanisms? Is there some sort of standard key management system that I'm unaware of? If not, why was IPC implemented without addressing this problem? The current IPC identifier scheme is designed for speed in the use of the IPC operations (eg. msgsnd, msgrcv), yet is limited to a fixed number of IPC identifiers that is determined at kernel configuration time (msgmni, semmni, shmmni). Will/has this problem been addressed? -Randy -- Randy Smith wsmith@cs.umn.edu ...!rutgers!umn-cs!wsmith
torek@horse.ee.lbl.gov (Chris Torek) (06/03/91)
In article <1991Jun2.234335.12694@cs.umn.edu> wsmith@cs.umn.edu (Warren Smith [Randy]) writes: >... Is there some sort of standard key management system that I'm >unaware of? There is a hack based on device and inode numbers, but it is just a hack. >If not, why was IPC implemented without addressing this problem? The IPC that wound up in System V was never intended as a general facility. It exists because a special-purpose application running on a special-purpose kernel had to move to a generic kernel, so they stuck in a special-purpose IPC. Unforunately, `they' were USDL, the group in charge of System III. Now you know. :-) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
benson@odi.com (Benson I. Margulies) (06/03/91)
There is, however, a trivial circumvention. Create kets with IPC_PRIVATE. Pass them to the other players in files or whatever. Then collisions are impossible. -- Benson I. Margulies