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

V>>Существует ли возможность определить, что очередь оказалась в такой "нештатной" блокировке, и вернуть очередь в рабочее состояние?

R>Если это именно мьютекс, то ОС освободит его при смерти процесса. Скорее всего там используется не мьютекс, а семафор или что-то самопальное.
нет там внутри этой эмуляции очереди обыкновенный pthread_mutex_t созданный в шареной памяти с аттрибутом PTHREAD_PROCESS_SHARED

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

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

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

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