On 8/14/06, John Carter <john.carter / tait.co.nz> wrote:
> I'm have a generic Daemon class exactly like Process.fork but
> Daemon.spawn does things like...
>
> * Check, via a lock file, that another copy of itself isn't running
>    somewhere.
>
> * Has a method to kill all copies of itself (via fuser)
>
> * Detaches itself from the controlling terminal (making it self a true
>    Daemon) so it doesn't die if parent process dies.
>
> * Can wait until the dameon has started, can wait for it to die.
>
> I suspect I could use fcntl and mandatory locking, but I'm not sure that
> would help with this problem.
>
> Ps: (What do Windowsy types do instead of "Process.fork"? )


I have to say that in my opinion, none of the problems you're trying
to solve are particularly deep nor particularly new. Stick with the
tried and true rather than inventing new practice. On Unix, just use
flock in the standard way. Don't worry about lockfile clutter- that's
what /tmp and /var/run are for. Advisory locks vanish with file
descriptors which makes them graceful when things go wrong. Like any
"mutex" object, hold them for the shortest possible period of time and
make sure you're not susceptible to hanging while you hold one-
otherwise you will go mad once you are in production.

Don't use anything that involves scanning /proc: that locks you not
only to specific Unixes but even to specific versions. Don't use
mandatory locks: this isn't what they were designed for and they are
extremely painful when things go wrong.

On Windows, don't cry, just use CreateProcess. Windows has a strong
cross-process mutex, unlike Linux, so use it. It's heavyweight, but so
what? Nothing is heavier than a process, which is what you're trying
to sync in the first place.