ShippingEasy/resque-pool — pull request #2 by brasic (2014-11-09 20:31:44+00:00)
Title: Support holding a shared lock on a designated file forever

This is to support running resque-pool inside of upstart while allowing for zero-downtime restarts. It enables the use of [this strategy](http://orchestrate.io/blog/2014/03/26/tip-seamless-restarts-with-unicorn-and-upstart/).

The idea is that when the pool starts, it opens a shared lock that it will hold forever that a process manager can use to detect liveness across restarts.

In the envisioned use-case, upstart is responsible for restarting a resque-pool if it fails. When resque-pool daemonizes, upstart keeps track of the process id. However, to ensure no downtime, we do not stop and start the pool. Instead, when a deploy happens, a new resque-pool instance will start and kill the old one after it is ready to fork workers. This would ordinarily cause upstart to detect that the original process has died and relaunch it, which is not desired behavior. If the upstart init script tries to obtain an exclusive lock, this attempt will block while any pool instance is still running, including ones other than the initial process.

This would normally be implemented in the `resque:pool:setup` task, but this happens after daemonization and the lock has to be obtained before the process backgrounds itself.