System V IPC
Everyone hates System V IPC. It’s slower than paper tape, carves out insidious little namespaces completely unrelated to the filesystem, uses human-hostile numbers to name its objects, and is constantly losing track of its own mind. Every so often, your sysadmin has to go on a search-and-destroy mission to hunt down these lost SysV IPC objects with ipcs(1) and kill them with ipcrm(1), hopefully before the system runs out of memory.
Despite all this pain, ancient SysV IPC still has a few valid uses. The three kinds of IPC objects are shared memory, semaphores, and messages. For message passing, sockets are the preferred mechanisms these days, and they’re a lot more portable, too. For simple uses of semaphores, the filesystem tends to get used. As for shared memory—well, now there’s a problem for you. If you have it, the more modern mmap(2) syscall fits the bill, but the quality of the implementation varies from system to system. It also requires a bit of care to avoid letting Perl reallocate your strings from where mmap(2) put them.
File::Map CPAN module makes this a lot easier. It still requires some
care in handling, but if you mess things up it just warns you instead of
dumping core with a segmentation violation.
Here’s a little program that demonstrates controlled access to a shared memory buffer by a brood of sibling processes. SysV IPC objects can also be shared among unrelated processes on the same computer, but then you have to figure out how they’re going to ...