Richard van Ulden wrote:
> I'm running a daemon process providing a shared memory interface towards
> its "clients".
> (This is all running on the same box)
>
> Unrelated (no child processes) clients attach to this Daemon using a
> "well known key".
>
> Once this Daemon is alive and kicking it creates a shared memory struct.
> In this struct the PID of this daemon is present.
>
> This type of IPC is chosen (instead of sockets) for the massive data
> structs I need to shared with clients. It's also much faster.
>
>
> For my application it is quite important that clients attached to this
> interface are aware of the status of the daemon.
>
> Keep in mind that the shared memory block remains present when the
> daemon dies for some reason.
>
> When the daemon gets killed voluntarily the shared mem is marked for
> deletion but not removed untill the last client detaches.
>
> When the daemon gets killed unvoluntarily the shared mem is not even
> marked for deletion.
>
> Questions:
>
> How can clients check the status of the daemon??
The most straightforward approach that I can think of is to create a
file, and have the daemon obtain a write lock on part of the file. A
client can then use fcntl(F_GETLK) to check whether the lock exists
(the lock will be released automatically if the daemon dies).
> Using kill (DEAMON_PID,0) is not a real solution, since clients could be
> run as user NOBODY and therefor have no privileges to do this.
>
> Let me know if anyone sees a good technique for checking the status of
> an unrelated process.
Any method based upon a stored pid suffers from the problem that if
the daemon dies, the pid could then be allocated to a different
process.
> I have a feeling that semaphores could bring something, please comment.
> Besides the fact that semaphores look quite complicated, I couldn't find
> any examples that fit in above concept. Any example is welcome.
SysV IPC semaphores are probably excessively complex in this case
(i.e. when you only need a single semaphore, rather than the ability
to lock multiple semaphores atomically).
--
Glynn Clements <[EMAIL PROTECTED]>
