Boost logo

Boost Users :

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2008-07-29 13:02:46


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.

> 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.

> 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.

Regards,

Ion


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net