Devin Ben-Hur <[email protected]> wrote: > Excellent points Michael. But to Bráulio's original request, it > would be lovely to factor out the clean and robust process > management parts of unicorn (daemonization, pidfile-mgmt, pre-load, > fork, reap, signaling) separate from the HTTP/Rack server.
I think some projects exist nowadays (and were inspired by unicorn). I also cannot speak to the quality of them, though. My take is that stuff ends up being fairly specific to the type of app used and putting an abstraction around them makes it harder to learn and use than the lower-level primitives Ruby provides. The ordering of some things (e.g. writing pid file, preload, binding sockets, hooks, timeout checks) seems subject to the needs of the specific server; and it's easier to figure out the ordering of those things when the lower-level parts are right in front of you instead of abstracted away in a library. Having Ruby as an abstraction around C syscalls is great since I don't have to worry about things like buffer overruns or error-checking every single syscall. More abstraction than that ends up hiding too many important details, making programming and maintenance harder.
