Можно про SHA почитать: http://en.wikipedia.org/wiki/SHA1

Или про CRC: http://www.microconsultants.com/tips/crc/crc.txt

HTH

Вышла новая OPERA

Нужен для расчёта ключа по символьному имени для shared memory System V

Стандарные функции расчёта ключа для System V возращают слишком малое значение. Какое максимальное значение ключа для System V?

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 бита

>Нужен для расчёта ключа по символьному имени для shared memory System V

а ftok(3) не пробовали?

qqq

Пробовал. Ей нельзя подсовывать длинные строки :(

> Пробовал. Ей нельзя подсовывать длинные строки :(

Да ей вроде и короткие подсовывать нельзя :-D

А в чем проблема? ftok() справляется со своей функцией генерации
уникальных ключей для SysV IPC. Для чего ей надо подсовывать
какие-то "длинные строки"?

HTH

qqq

Как это было в 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 вообще
не нужно)

HTH

Вдогонку: если твоя конкрентная версия Linux не умеет POSIX shared
memory ты можешь использовать вместо нее обычный memory mapped file.
HTH

qqq

Интересное мнение. Ссылку на доки в студию!

Покажи рабочий пример обмена данными между двумя процессами (а не потоками).

ййй

с удовольствием почитаю доки по этим темам. Дайте пожалуйста ссылки.

> Интересное мнение. Ссылку на доки в студию!

man shm_open

Ну и Стивенса там почитай что-ли, погугли...

(или используй, как я уже сказал, обычный memory mapped file)

> Покажи рабочий пример обмена данными между двумя процессами
> (а не потоками).

В чем именно у тебя проблема?

qqq

стивенса читали, от shm_open() отказался, т.к. немного глюкавая вещь. Например если сделать 127 раз shm_open()/shm_unlink() то оно падает.

Кроме того System V для unix систем стандартные.

> стивенса читали, от shm_open() отказался, т.к. немного глюкавая вещь.

Тогда твой вопрос непонятен :-/
OK, ты отказался от POSIX shared memory потому, что они "глючат". Твое право.
Но тогда откуда твой тезис о том, что якобы POSIX shared memory
на Linux не работает для разных процессов?

> Например если сделать 127 раз shm_open()/shm_unlink() то оно падает.

Чота сомневаюсь :-/

> Кроме того System V для unix систем стандартные.

Аналогично и memory mapped files - open/mmap есть везде.

HTH

> В линухе именованной шаред мемори нет.

а что мешает создать файл нужного размера и сделать mmap на него?
Вот тебе и shared memory причем именованная.

> от shm_open() отказался, т.к. немного глюкавая вещь. Например если сделать 127 > раз shm_open()/shm_unlink() то оно падает.

кто оно, ядро или ваша программа? а вы уверены что это вызванно не вашим неправильным его использованием или ошибками которые просто не проявились на qnx?

ййй

На данный момент мне нужен алгоритм генерации ключа из длинного символьного имени. С shared memory System V проблем почти нет. За исключением этого момента:

http://www.linux.org.ru/view-message.jsp?msgid=1346251

> На данный момент мне нужен алгоритм генерации ключа из длинного
> символьного имени. С 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
с одним и тем же ключом? Это все равно, пытаться сделать два разных
файла с одним и тем же полным именем.

HTH