Являются ли очереди сообщений устаревшими в linux?

Question

Являются ли очереди сообщений устаревшими в linux?

Я недавно играл с очередями сообщений (System V, но POSIX тоже должен быть в порядке) в Linux, и они кажутся идеальными для моего приложения, но после прочтения Искусства программирования Unix я не уверен, что они действительно хороший выбор.

http://www.faqs.org/docs/artu/ch07s02.html#id2922148

верхний уровень передачи сообщений системы V IPC в значительной степени вышел из употребления. Нижний уровень, который состоит из общей памяти и семафоры, по-прежнему имеет значительные приложения в условиях, в которых необходимо сделать взаимное исключение блокировки и некоторый глобальный обмен данными между процессами, работающими на одной машине. Эти средства общей памяти System V превратились в API общей памяти POSIX, поддерживаемый под Linux, BSD, MacOS X и Windows, но не классический MacOS.

http://www.faqs.org/docs/artu/ch07s03.html#id2923376

система V IPC средства присутствуют в Linux и других современных Unixes. Однако, поскольку они являются унаследованной функцией, они не очень часто используются. Версия Linux, как известно, все еще имеет ошибки по состоянию на середину 2003 года. Никто, кажется, не заботится достаточно, чтобы исправить их.

очереди сообщений System V все еще глючат в более поздних версиях Linux? Я не уверен, что автор означает, что очереди сообщений POSIX должны быть в порядке?

кажется, что сокеты являются предпочтительным IPC для почти ничего(?), но я не вижу, как было бы очень просто реализовать очереди сообщений с сокетами или что-то еще. Или я слишком много думаю?

Я не знаю, имеет ли значение, что я работаю со встроенным Linux?

742 4

linux sockets ipc posix

4 ответов:

Comments

Ничего не найдено.

Duck · Accepted Answer · 2009-06-09 03:02:33

лично я очень люблю очереди сообщений и думаю, что они, возможно, являются наиболее недоиспользуемым IPC в мире unix. Они быстры и просты в использовании.

пара мыслей:

некоторые из них просто мода. Старые вещи снова становятся новыми. Добавьте блестящий do-dad в очереди сообщений, и они могут быть самой новой и горячей вещью в следующем году. Посмотрите на Chrome от Google, используя отдельные процессы вместо потоков для своих вкладок. Вдруг люди взволнован тем, что когда одна вкладка блокируется, она не сбивает весь браузер.

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

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

варианты System V действительно впали в немилость. Как правило, идут с POSIX версии IPC, когда вы можете.

MarkR · Accepted Answer · 2009-06-09 10:02:22

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

Linux позволяет монтировать очереди сообщений posix как файловую систему и видеть их с помощью "ls", удалять их с помощью "rm", что тоже очень удобно (System V зависит от неуклюжих "ipcs" и " ipcrm" команды)

bmdhacks · Accepted Answer · 2016-05-06 23:18:30

Я на самом деле не использовал очереди сообщений POSIX, потому что я всегда хочу оставить открытой возможность распространять мои сообщения по сети. Имея это в виду, вы можете посмотреть на более надежный интерфейс передачи сообщений, такой как zeromq или что-то, что реализует AMQP.

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

shuva · Accepted Answer · 2018-06-14 15:28:20

самые большие недостатки очереди сообщений POSIX:

очередь сообщений POSIX не делает его требование чтобы быть совместимым с select().(Он работает с select() в Linux, но не в системе Qnx)

у него есть сюрпризы.

сокет датаграммы Unix выполняет ту же задачу очереди сообщений POSIX. И сокет дейтаграммы Unix работает в слое сокета. Можно использовать его с select()/poll() или другие методы IO-wait. С помощью select()/poll() имеет преимущество при проектировании системы на основе событий. Таким образом, можно избежать цикла занятости.

есть сюрприз в очереди сообщений. Думал о mq_notify(). Он используется для получения receive-event. Похоже, мы можем уведомить что-то о очереди сообщений. Но на самом деле это регистрация для уведомления, а не уведомление о чем-либо.

еще один сюрприз о mq_notify() это то, что он должен быть вызван после каждого mq_receive(), что может привести к race-condition(когда какой-то другой процесс/поток вызывает mq_send() между призывом mq_receive() и mq_notify()).

и он имеет целый набор mq_open, mq_send(), mq_receive() and mq_close() С их собственным определением, которое является избыточным и в некоторых случаях противоречит гнездо open(),send(),recv() and close() спецификация метода.

я не думаю, что очередь сообщений должна использоваться для синхронизации. eventfd и signalfd подходят для этого.

но Он (очередь сообщений POSIX) имеет некоторое реальное время поддержка. Он имеет приоритетные функции.
Messages are placed on the queue in decreasing order of priority, with newer messages of the same priority being placed after older messages with the same priority.
но этот приоритет также доступен для сокета как внеполосные данные !

наконец , для меня очередь сообщений POSIX-это устаревший API. Я всегда предпочитаю сокет датаграммы Unix вместо очереди сообщений POSIX, если функции реального времени не нужны.