смысл функции ftok()

The ftok() function shall return a key based on path and id that is usable in subsequent calls to msgget(), semget(), and shmget(). The application shall ensure that the path argument is the pathname of an existing file that the process is able to stat().

The ftok() function shall return the same key value for all paths that name the same file, when called with the same id value, and return different key values when called with different id values or with paths that name different files existing on the same file system at the same time. It is unspecified whether ftok() shall return the same key value when called again after the file named by path is removed and recreated with the same name.

Другими словами, ~/.keyfile, ./.keyfile и /home/me/symlink_to_key должны вернуть один и тот же ключ.

вот пример использования: http://pubs.opengroup.org/onlinepubs/009696899/functions/semget.html

как я понимаю тут главное в том, что-бы не получилось одинаковых ключей.

Of course no guarantee can be given that the resulting key_t is unique. Typically, a best effort attempt combines the given proj_id byte, the lower 16 bits of the inode number, and the lower 8 bits of the device number into a 32-bit result. Collisions may easily happen, for example between files on /dev/hda1 and files on /dev/sda1.

смысл в том что файл твой - ты его создаешь - это твой ключ. почему именно файл? потому что он виден из разных процессов и потому что «ВСЕ - ФАЙЛ»

Другими словами, ~/.keyfile, ./.keyfile и /home/me/symlink_to_key должны вернуть один и тот же ключ.

Не, там по идее хардлинк нужен, чтобы inode был одинаковый

stat статит файл под симлинком, а не сам симлинк. Вообще давно бы уже проверил с разными путями и разными линками. По мне так все однозначно: shall return the same key value for all paths that name the same file.

выкинь это дерьмо мамонта и используй posix ipc (если уж вообще такая низкоуровщина нужна)

И зачем вообще опираться при генерации IPC ключа на некий файл в файловой системе?

А зачем ты опираешься? Забульбень некое случайное число в файлик /tmp/your_IPC. И читай его оттуда... Упс. А ведь та же хрень получится... ☺

В Posix IPC механизм shared memory вроде как работает через mmap с параметром MAP_SHARED, потом процесс форкается, после чего два процесса могут эту общую память читать-писать, тогда как в SysV IPC кусок shared memory выделяется через shmget(), к нему можно спокойно подцепиться из другого процесса и работает это без всяких ненужных форков. Подход в SysV мне кажется более рациональным т.к. в случае с mmap MAP_SHARED надо все начинать с одного исполняемого файла, который порождает один процесс, который потом должен форкаться, это все усложняет.

Если я что-то тут напутал по незнанию, прошу указать на ошибки и посоветовать насчет того, где почитать про POSIX IPC

man shm_open

A POSIX shared memory object is in effect a handle which can be used by unrelated processes to mmap(2) the same region of shared memory.