Background jobs with #fork
normalperson at yhbt.net
Fri Apr 13 02:10:54 UTC 2012
Patrik Wenger <paddor at gmail.com> wrote:
> > 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!
No problem. I've also pushed it out as a commit + test case:
I'm looking at releasing unicorn 4.3.0 early next week, probably
Tuesday (including REQUEST_PATH/REQUEST_URI length limit tweaks).
> 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.
Sorta, I think I conflated the shutdown vs releasing resources a bit.
Releasing kernel resources happens for all file descriptors.
However, connected sockets may negotiate a graceful termination
of the connection, and that's what shutdown() can do. However,
close() will do it implicitly.
If a kernel were implemented in Ruby, close() would be something like
this, showing how shutdown() can get called automatically:
# assume @fd_map is an array mapping fd to file/socket objects
io_object = @fd_map[fd]
return Errno::EBADF if io_object.nil?
# allow +fd+ to be reused immediately
@fd_map[fd] = nil
io_object.refcount -= 1
# if there are no more references, do other work:
if io_object.refcount == 0
# assume this is idempotent
# free memory and any other resources allocated
More information about the mongrel-unicorn