[C][shmem][malloc][нубство] управление shared memmory и другие вопросы

> Есть ли аналог malloc(), только чтобы выделял память из shm-сегмента?

Нет. Наверное, можно как-то залезть в потроха malloc и сделать свои обертки, но это довольно плохая идея.

SysV mq более переносим, чем POSIX mq, но, подозреваю, тебе не нужно ни то, ни другое. У нас с MuZHiK-2 был когда-то флейм на эту тему.

И malloc в shmem тебе тоже вряд ли нужен.

Есть ли средства организации очередей сообщений основанные на shmem? Язык программирования C.

zeromq :)

Спасибо, думал над этим :). Просто поток данных большой между двумя приложениями запущенными локально.

На всякий случай расскажу задачу :). Была программа которая состояла из нескольких модулей(ввод данных, обработка, вывод). Я решил её распилить на несколько процессов и добавить возможность принимать данные сразу с нескольких источников. Заодно это улучшит стабильность(кривые плагины не завалят основной процесс) и даст возможность писать различные модули на любом удобном языке и с любой архитектурой(щас всё очень жёстко в плане архитектуры из-за особенностей основного цикла программы). И вот щас я думаю как уменьшить оверхед передачи данных между прогами. shmem нравится тем что не надо делать сериализацию достаточно сложных вложенных структур. Но зато у сокетов есть буферизация.

(но на данном этапе мне интересно понять как сделать проще всего, фиг с производительностью)

Проще всего - на сокетах.

в общем, я решил domain sockets + SOCK_DGRAM(чтобы не париться с отделением отдельных пакетов(framming) друг от друга в SOCK_STREAM) и пересылать данные в сыром виде чтобы не париться с сериализацией. Что скажешь? Выдержит сотню пакетов в секунду без особого оверхеда? :)

Оно выдержит, но зачем тебе Unix Domain Sockets? Думаю, локальный TCP достаточно быстр, ты наверняка умеешь с ним работать и в качестве бонуса получаешь возможность разнести плагины по разным машинам.

с tcp гемора сильно больше он connection-based protocol.

Event loop основной проги может вызывать только одну функцию get_data() и этот get_data() должен давать данные. Т.е. точка входа в наш код только одна.

А вот если мы делаем tcp то там придётся плодить обработчики on_accept(), on_read(), on_error() (три точки входа) и всё это как-то заставлять работать вместе, либо городить огород и в одной функции и принимать соединения и обрабатывать их и закрывать. Придётся городить огород и не получится юзать libevent(или аналоги) т.к. он расчитан на другой паттерн программирования(в нём каждому типу событий соответствует свой обработчик типа on_accept()/on_error()/etc). Кроме того, get_data() может за раз принять данные только от одного источника данных :(

И к тому же при tcp придётся заморочится чтобы резать входной поток на пакеты. А тут простой код:

client, data = recvfrom()
answer = process_data()
send(client, answer)

Т.е. кода сильно меньше :). Только udp нельзя т.к. он может потерять или перетусовать пакеты, а переизобретать tcp не хочется.

Ну и специфика кода такова что сам «обработчик» умеет пересылать данные для обработки на другие узлы и сам он проц не жрёт (на самом деле обработкой занимаются выходные модули которые работают на других узлах). Поэтому обработчик запускается на каждой тачке которая данные принимает, выносить входные и выходные модули на отдельные узлы не требуется.

По моему мнению с AF_UNIX и PF_DGRAM получается самый простой и читабельный код, поэтому и хочу юзать :)

Ну и zeromq прямо в тему. Тэйлганнера по поводу сокетов не слушай, с ними геморроя по сравнению с zeromq - вагон и маленькая тележка. У zeromq куча use case'ов, пачка разных вкусных транспортов, и поддержка штук 15 языков.

> У zeromq куча use case'ов, пачка разных вкусных транспортов, и поддержка штук 15 языков.

...и модель использования, скопированная с сокетов? :)

Просто это чудовищный overkill для такого маленького проекта :). Да, zeromq решает эту и ещё две тыщи задач, но тут на сокетах в 50 строк решается, я решил не тащить в проект ещё зависимостей. Но спасибо что помогал решать проблему.

Вообще подумал и решил что может даже sys V message queues будет достаточно, ничего более сложного не требуется. Только проблема в том что там нет файлового дескриптора на котором мы можем делать select(). Буду ещё думать.

Ты сначала напиши на zeromq (в порядке прокачки скиллзов :), а потом на сокетах/сообщениях. Уверен, что в процессе переписывания мнение о пользе сего действия в корне изменится ;)

Зато можно узнавать, есть ли сообщения в очереди. Только, боюсь, в вашем случае очереди не помогут (т.к. вы писали, что информации много, т.е. вполне может быть, что либо очередей не хватит, либо их размер будет недостаточным для некоторых сообщений).

Спасибо, надо будет обязательно проверить. Мне бы мегабайт на 8 буфера бы хватило точно. Ну и чтобы сообщений 100 влезало хотя бы :). Щас сяду проверять.

Хорошо, попробую, спасибо :). Но проблема в том что у «обработчика» такой eventloop что впихивать туда либы очень сложно. Впрочем, я его перепишу нафиг, а то так и будем топтаться на месте.

Не помню, какое там ограничение. Я выделял до 1024 сообщений с размером в 256 байт. По умолчанию максимальный размер одного сообщения 8к (но и не больше 10). См. /proc/sys/fs/mqueue/*

Спасибо, надо будет обязательно проверить. Мне бы мегабайт на 8 буфера бы хватило точно. Ну и чтобы сообщений 100 влезало хотя бы :). Щас сяду проверять.

Кернельные очереди копируют данные два раза: из процесса в ядро, из ядра в другой процесс. Нафиг бы оно надо было, когда есть очереди, использующие shmem.

Нафиг бы оно надо было, когда есть очереди, использующие shmem.

Но там надо еще дополнительно обрабатывать сигналы...

> Мне бы мегабайт на 8 буфера бы хватило точно. Ну и чтобы сообщений 100 влезало хотя бы :)

Ты собираешься пересылать 800М/с?

нет, просто вдруг обработчик где-нить заблокируется или тачка лаганёт, не хочу чтобы процесс передачи данных упёрся в маленькие буфера. А так трафика там в ближайшем будущем не более пары метров в секунду и сотни пакетов.

Согласен, поэтому про shmem и спрашивал :)

угу, посмотрел sysctl -a | grep msg, даже попробывал различные большие значения поставить, работает :). Буду думать.

Вы все таки подумайте, есть ли смысл использовать очереди сообщений? Я лично их использовал т.к. клиент, читающий сообщения, запускался с некоторой периодичностью, в то время как сервер отсылал сообщения асинхронно. Плюс клиент должен был иметь возможность прочитать последние сообщения сервера после отключения последнего.