Я знаю, что IPC_PRIVATE сгенерирует уникальный ключ при вызове shmget () для его создания
Нет, вы неправильно поняли. IPC_PRIVATE
не генерирует a key_t
, оно равно a key_t
. Это специальное key_t
вызывает специальное поведение из shmget()
всегда создавать новый сегмент, игнорируя все биты флагов, кроме битов режима.
если мне тогда нужен этот ключ, чтобы открыть этот регион где-то в других процессах, как я могу получить доступ к этому сгенерированному значению key_t, чтобы я мог отправить его другому процессу?
Так как вы всегда получаете новый сегмент с IPC_PRIVATE
, вы не можете разделять память между процессами каждым независимо получая сегмент общей памяти через этот ключ. Вместо этого, чтобы два или более процесса могли обмениваться данными через такой сегмент, все они должны унаследовать его от общего процесса-предка, который его создал (или быть процесса, который его создал). Процессы, которые не имеют такой взаимосвязи друг с другом, не могут использовать клавишу IPC_PRIVATE
для доступа к одному и тому же сегменту.
У меня нет других вариантов, кроме как попытать удачу с помощью ftok () и некоторых случайных файлов? Нужно ли выбирать разные файлы для каждого блока разной общей памяти, которую я хочу создать?
Поскольку вы используете разделяемую память System-V, у вас есть альтернатива использованию ftok()
для генерации ключей на основе существующего пути, но это не обязательно должен быть произвольный файл , Вы можете использовать путь к файлу, который характерен для определенной группы взаимодействующих процессов - входной файл, рабочий каталог или аналогичный. Более того, ftok()
также использует целочисленный «идентификатор проекта», с помощью которого вы можете различать не связанные прогоны, или несколько различных ключей, служащих разным целям, или похожих. Вы можете выбрать там идентификатор процесса какого-либо назначенного процесса, если у вас нет другого хорошего способа различения.
Кстати, обратите внимание, что интерфейсы System-V IPC довольно неуклюжи. У них есть пара отличительных особенностей, которые иногда могут сделать их предпочтительными, но более новые интерфейсы POSIX (shm_open()
и т. Д.) Обычно являются лучшим выбором. Однако версии POSIX не предлагают особенно лучшего решения проблемы, о которой вы спрашивали.