> Actually, I think my proposed patch (in reply to Hongli) at > http://mid.gmane.org/[email protected] > 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. _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
