Re: [boost] boost.shmem bugs

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-07-08 08:46:20

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