On Thu, Apr 12, 2012 at 10:39 PM, Eric Wong <[email protected]> wrote: >> The problem persists even when multiple workers are started. And the >> problem was not present in the old setup with Passenger. >> >> My question: Does Unicorn somehow check/wait for child processes >> forked by the worker processes? > > Unicorn workers do not explicitly wait on child processes themselves, > unicorn workers set: trap(:CHLD,"DEFAULT") after forking, even (the > unicorn master must handle SIGCHLD, of course) > > The difference between nginx+unicorn and Passenger is probabably: nginx > relies on unicorn generating an EOF to signal the end-of-response (nginx > <-> unicorn uses HTTP/1.0), this I'm sure about. I think Passenger uses a > protocol which can signal the end-of-request inline without relying on > an EOF on the socket (Hongli can correct me on this if I'm wrong).
We don't. We call #close_write on the socket to prevent this problem. #close_write calls shutdown(fd, SHUT_WR) which isn't affected by the number of processes that have inherited the socket handle. -- Phusion | Ruby & Rails deployment, scaling and tuning solutions Web: http://www.phusion.nl/ E-mail: [email protected] Chamber of commerce no: 08173483 (The Netherlands) _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
