Background jobs with #fork

Patrik Wenger paddor at gmail.com
Fri Apr 13 01:04:24 UTC 2012


> Actually, I think my proposed patch (in reply to Hongli) at
> http://mid.gmane.org/20120412221022.GA20640@dcvr.yhbt.net
> should fix your issue.

Oh, this sounds great! I see it's just one line. I'll try adding this line and see if it fixes my problem.
Thanks already!

> Basically, fork() has a similar effect as dup() in that it creates
> multiple references to the same kernel object (the client socket).
> 
> close() basically lowers the refcount of a kernel object, when the
> refcount is zero, resources inside the kernel are freed.  When
> the refcount of a kernel object reaches zero, a shutdown(SHUT_RDWR)
> is implied.
> 
> This works for 99% of Rack apps since they don't fork() nor call dup()
> on the client socket, so refcount==1 when unicorn calls close(), leading
> to unicorn setting refcount=0 upon close() => everything is freed.
> 
> However, since the client socket increments refcount via fork(),
> close() in the parent (unicorn worker) no longer implies
> shutdown(SHUT_RDWR).

I don't know much about system calls (honestly, never heard of shutdown() before) but I think I understand.
The kernel then doesn't fee the allocated client socket and thus Unicorn (or Nginx? That's the other end of the client socket, I think...) thinks there's still more to come.


More information about the mongrel-unicorn mailing list