Typically, a best effort attempt combines
the given proj_id byte, the lower 16 bits of the i-node
number, and the lower 8 bits of the device number into a
32-bit result.
Так что видимо максимум это int целочисленный тоесть 32 бита
> Пробовал. Ей нельзя подсовывать длинные строки :(
Да ей вроде и короткие подсовывать нельзя :-D
А в чем проблема? ftok() справляется со своей функцией генерации
уникальных ключей для SysV IPC. Для чего ей надо подсовывать
какие-то "длинные строки"?
Как это было в qnx4, qnx6:
два процесса обмениваются данными через именованную шаред мемори.
В линухе именованной шаред мемори нет. Прихидится использовать имя, конвертить его в ключ.
> Как это было в qnx4, qnx6: два процесса обмениваются данными через
> именованную шаред мемори. В линухе именованной шаред мемори нет.
> Прихидится использовать имя, конвертить его в ключ.
В Linux есть SysV shared memory и POSIX shared memory.
SysV shared memory идентифицируется ключами, POSIX shared memory
идентифицируется путями в файловой системе (именами).
Или ты хочешь сказать, что в QNX еще какая-то третья shared memory
есть?
не третья, а стандартная именованная POSIX shared memory, но её можно использовать для межпроцессного обмена. А Линуховую именованную shared memory можно использовать только для межпоточного обмена в контексте одного процесса.
Мне надо что бы процессы асинхронно запускающиеся друг относительно друга, могли обмениваться данными через shared memory, поэтому пришлось использовать shared memory System V, а имя конвертить в ключи. Имена длинные.
> не третья, а стандартная именованная POSIX shared memory, но её
> можно использовать для межпроцессного обмена. А Линуховую
> именованную shared memory можно использовать только для межпоточного
> обмена в контексте одного процесса.
>
Ржунимагу :-))) "А пацаны-то не знают" (C)
С какого это перепуга в Linux POSIX shared memory нельзя использовать
для межпроцессного обмена? Откуда ты это взял?
(кстати - в контексте одного процесса никакой shared memory вообще
не нужно)
> стивенса читали, от shm_open() отказался, т.к. немного глюкавая вещь.
Тогда твой вопрос непонятен :-/
OK, ты отказался от POSIX shared memory потому, что они "глючат". Твое право.
Но тогда откуда твой тезис о том, что якобы POSIX shared memory
на Linux не работает для разных процессов?
> Например если сделать 127 раз shm_open()/shm_unlink() то оно падает.
Чота сомневаюсь :-/
> Кроме того System V для unix систем стандартные.
Аналогично и memory mapped files - open/mmap есть везде.
> от shm_open() отказался, т.к. немного глюкавая вещь. Например если сделать 127 > раз shm_open()/shm_unlink() то оно падает.
кто оно, ядро или ваша программа? а вы уверены что это вызванно не вашим неправильным его использованием или ошибками которые просто не проявились на qnx?
На данный момент мне нужен алгоритм генерации ключа из длинного символьного имени. С shared memory System V проблем почти нет. За исключением этого момента:
> На данный момент мне нужен алгоритм генерации ключа из длинного
> символьного имени. С shared memory System V проблем почти нет. За
> исключением этого момента:
>
> http://www.linux.org.ru/view-message.jsp?msgid=1346251
Этот твой "момент" непонятен. Что тебя так беспокоит?
Читаем описание shmget():
.....................
A shared memory identifier, associated data structure, and shared
memory segment of at least size bytes (see <sys/shm.h>) are created
for key if one of the following is true:
- The argument key is equal to IPC_PRIVATE.
- The argument key does not already have a shared memory identifier
associated with it and (shmflg &IPC_CREAT) is non-zero.
.....................
Как ты это себе представляешь создание двух разных shared memory
с одним и тем же ключом? Это все равно, пытаться сделать два разных
файла с одним и тем же полным именем.