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

From: Sachin Garg (schngrg_at_[hidden])
Date: 2008-07-29 15:20:55

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