Background jobs with #fork

Eric Wong normalperson at
Fri Apr 13 02:10:54 UTC 2012

Patrik Wenger <paddor at> wrote:
> > Actually, I think my proposed patch (in reply to Hongli) at
> >
> > 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:

  def SYS_close(fd)
    # 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
      if io_object.kind_of?(Socket)
        # assume this is idempotent
        SYS_shutdown(fd, SHUT_RDWR)

      # free memory and any other resources allocated

More information about the mongrel-unicorn mailing list