Здравствуйте, zaufi, Вы писали:

Z>Здравствуйте, remark, Вы писали:

Z>нет там внутри этой эмуляции очереди обыкновенный pthread_mutex_t созданный в шареной памяти с аттрибутом PTHREAD_PROCESS_SHARED

Z>т.е. при смерти одного процесса еси не почистить эту саму память (что конечно же грязный хак) он останется там залоченым

Z>фигня в том что из прикладного кода добраться до этого mutex'a топикстартеру буит аццки не просто (если вообще возможно... ну конечно всегда можно похакать буст %) ... так что второй совет в этом thread'e (повеситься на SIGSEGV и делать unlock) также реализуем с невероятным трудом

Z>теперь об эмуляции: заглянув в исходнеки был разочарован что message_queue этот на сам деле ни какой не POSIX message queue (see mans: mq_open, mq_close, mq_send, mq_receive), а тупо шареная память и интерпроцессный mutex...

Boost видимо из-за своей кроссплатформенности не может использовать нативно POSIX message queue. Под windows этот вариант не прокатит.

Z>топикстартеру рекомендую ознакомиться с `man 7 mq_overview`. от себя добавлю что в POSIX message queue ни кааких локов не требуется вв юзерском коде пользоваться легко и удобно (с помощью простецких С++ных врапперов конечно же %) которые к слову говоря сильно проще чем в бусте накрученная эмуляция)... ну и кроме всего прочего нативные message queue умеют уведомлять процесс (каким скажешь сигналом) о пришедшем сообщении (не нада ничо полоть)

У нас проект в проекте не рекомендуется использовать чистый POSIX. Поэтому используется Boost.