Re: [Boost-users] [boost] [interprocess] Semaphore cleanup after crash

From: Sachin Garg (schngrg_at_[hidden])
Date: 2008-07-31 16:31:10

Ion,

I was wondering whats your take on this. Is it something that
can/should be added to boost or would you prefer that I just hack it
in my code only?

Sachin Garg

On Wed, Jul 30, 2008 at 12:50 AM, Sachin Garg <schngrg_at_[hidden]> wrote:
> On Tue, Jul 29, 2008 at 11:33 PM, Sachin Garg <schngrg_at_[hidden]> wrote:
>> On Tue, Jul 29, 2008 at 10:32 PM, Ion Gaztañaga <igaztanaga_at_[hidden]> wrote:
>>> Sachin Garg wrote:
>>>>
>>>> If a semaphore is not in-use (open) by any process, in this case (in
>>>> my application) I can safely 'remove' it and start afresh. Is there
>>>> some way to find out if any process is using a semaphore at a time so
>>>> that I can call 'remove'?
>>>
>>> Inteprocess is modeled after posix primitives, so there is no way to know if
>>> someone is attached. Think about this as if the semaphore was a file. What
>>> would you do if you are communicating two processes with a file and one
>>> process crashes? I think you should have some keepalive mechanism to detect
>>> that a process has died and recreate ipc mechanisms on failure.
>>
>> Yep, I understand this is the posix way of removing everything, be it
>> semaphores or other stuff. By keepalive do you mean having an umbrella
>> process to take care of recovering from such crashes? Or is it some
>> other standard mechanism that I am not aware of?
>>
>>>> When I just add a 'remove' on process start this works great on
>>>> windows (as remove just fails if another process has the semaphore
>>>> open), but on linux sem_unlink is used which has the behavior of
>>>> deleting it even if its in use.
>>>
>>> This same problem happens with std::remove(const char *filename) (windows
>>> version fails if the file is in use but unix version calls unlink and
>>> removes that file from the filesystem without failing while attached
>>> processes still write to that phantom file) but this is a difference I don't
>>> know how to solve.
>>
>> Yep. I tried forcing use of interprocess' cywgin and windows
>> implementation of named_semaphore on linux (just for experimenting) as
>> these are done differently. Windows one fails to compile and cygwin
>> implementation fails as that uses shm_unlink which works same as
>> sem_unlink, the posix way :-)
>>
>>>> What is the general practice when it comes to cleaning up semaphores
>>>> after process crashes? Maybe some way to ensure that 'post' and
>>>> 'close' are always called even when application has otherwise crashed?
>>>> Is there some way to use boost's windows style semaphores on linux
>>>> instead of native posix style?
>>>>
>>>> I tried looking and many have asked this question (in context of
>>>> recovering from posix semaphores, which are used by boost on linux),
>>>> but I couldn't find any answers. Lars had asked this here also, almost
>>>> an year ago but no answers in that thread either. This seems like a
>>>> basic issue but am totally lost on how to even approach it.
>>>
>>> In general I see no general solution. You can't register cleanup actions
>>> when a process crashes (well, the OS can, but not the user code). If anyone
>>> has any idea about this, I would be glad to hear it.
>>
>> The method discussed with Bob (in same thread), does that makes sense?
>> To programatically do what he proposes using commands.
>>
>> I am not aware of system calls for this but it seems possible (ipcs
>> does this 'somehow') to find which process last used a semaphore and
>> then it can be checked if that process id is still alive, and only
>> then we can call sem_unlink. All this can be abstracted with boost in
>> a smart_remove or a safe_remove. Idea being to sem_unlink only when no
>> other process is using it.
>>
>> If it doesn't looks like something of too much general value (though I
>> think it would be) I would atleast like to do this in my code, so any
>> pointers to relevant system calls will be really really helpful.
>>
>> Thanks for all the great work done in interprocess.
>
> ps. I figured something can be done using semctl/semget etc but they
> need sem's set id as parameter. Haven't yet figure out how to find
> that id for a posix named semaphore.
>
> Sachin Garg
>