Повысить очередь сообщений не на основе очереди сообщений POSIX? Невозможно выбрать (2)? - PullRequest
8 голосов
/ 03 января 2009

Я подумал, что я бы использовал Boost.Interprocess Очередь сообщений вместо сокетов для связи внутри одного хоста. Но после изучения этой проблемы, кажется, что эта библиотека по какой-то причине отказывается от возможности очереди сообщений POSIX (которую поддерживает моя система Linux) и вместо этого реализуется поверх общей памяти POSIX. Интерфейс достаточно похож, чтобы вы не могли сразу догадаться об этом, но, похоже, это так.

Недостатком для меня является то, что совместно используемая память, полученная с помощью shm_open(3), по-видимому, не может использоваться с select(2), в отличие от очередей сообщений POSIX, полученных с помощью mq_open(3).

В этом случае библиотека Boost проигрывает. Кто-нибудь понимает, знает, почему это должно быть? Даже если очереди сообщений POSIX доступны только в некоторых системах, я ожидаю, что Boost будет использовать эту возможность там, где она доступна, и переопределять ее только при необходимости. Есть ли какая-то ошибка системы POSIX, которую я еще не распознал?

Ответы [ 2 ]

4 голосов
/ 08 января 2009

Я столкнулся с подобной ситуацией на днях, когда использовал классы синхронизации Boost.Interprocess: а именно, класс условия. Он реализован «общим» способом, но способ, которым это было сделано, состоит в том, чтобы использовать пользовательскую спин-блокировку, которая очень неэффективна (по крайней мере, в OS X). По сути, это делало классы синхронизации бесполезными.

По моему опыту, библиотека Interprocess довольно незрелая. Я использую его для разделяемой памяти, и он работает довольно хорошо, но есть некоторые неровности, и мне пришлось взломать некоторые «недостающие функции», такие как динамическое изменение общей памяти и т. Д.

В целом, не ожидайте, что эта библиотека пока будет серебряной пулей. Это хорошо, но не исключение в настоящее время.

2 голосов
/ 04 декабря 2012

Да, к сожалению, это не так. Я тоже был разочарован, когда понял, что после копания источников.

Но есть и другая (хорошая) сторона этого факта: если ваша программа использует boost::asio, вы можете обернуть API очередей сообщений POSIX в просто еще одну дейтаграмму источник данных и это (IMHO) было бы даже лучше использовать, если бы он был частью boost::interprocess ... это было бы довольно нетривиально, но (IMHO) определенно заслуживает этого, так что вы можете работать с MQ унифицированным образом и использовать мощность другого boost::asio материала ...

... в моем следующем проекте, если мне снова понадобится POSIX MQ, я определенно поступлю следующим образом:)

...