Hi Dmitry,
1. If you hasn't semaphore support in your glibc libraries (in my case it was without TLS) "sem_open" function will return (sem_t*)0 instead of (sem_t*)-1 as it is described in my system header "semaphore.h". Plese correct file "shared_memory.hpp" for using SEM_FAILED macros.
Thanks! It seems that ((sem_t *)-1) was explicity used in some implementations and was documented like this, but you are right, OpenGroup specifies that the return value is SEM_FAILED. Corrected in sandbox-cvs.
2. Unclear sinuation. I wrote bugous example program where I write some data in shared_message_queue in infinity cycle without any timeout. If you stop program by Ctrl+C "boost_shmem_shm_global_mutex" stays in locked state so program will not work from second start. If you include some timeout in cycle then program will work properly.
This is strange. The infamous "boost_shmem_shm_global_mutex" global mutex is used to implement atomic system-wide initializations, and can be left locked if a process crashes in the atomic initialization (that's why I plan to use file locks in Boost.Interprocess, that are guaranteed to be unlocked automatically when a process crashes), but with a shared_message_queue this just can happen when opening, creating or destroying one. But never while sending receiving messages, since it's not used in those cases. The problem is that the message queue has a process-shared mutex and a condition variable constructed in shared memory to implement the queue and if you crash a process while holding the mutex, the queue is left in a corrupted state. I can't do anything to solve this, since I would need the OS to unlock all the resources if the owner dies. Nevertheless this does not guarantee anything, since the message queue state might be wrong (the program is crashed while manipulating internal queue pointers, for example). I'm sorry to tell you that POSIX async signals are really difficult to combine with a portable interprocess syncrhonization library. I would need help from UNIX experts to know what should I do to provide signal safe synchronization objects. Masking the signals just when entering the message queue functions does not seem very nice, since a process can stay blocked while a message arrives. Any ideas? Regards, Ion