rack/rack — pull request #671 by lenny (2014-03-27 21:21:53+00:00)
Title: Eliminate dependency on garbage collection for cleanup of Tempfiles created by Rack for multipart form data

Ideas/strategy extracted from posts by Eric Wong and Charles Oliver Nutter
https://groups.google.com/forum/#!searchin/rack-devel/temp/rack-devel/brK8eh-MByw/sw61oJJCGRMJ

I personally took interest in this after being forced to tinker with the JVM garbage collection settings of a JRuby/Trinidad server in order to prevent "Too many open file handle" errors. In our case, the service was running on a server flush with memory and garbage collection running extremely infrequently. Quoting Charles from the post above as to why depending on garbage collection is "less than ideal":

> It's roundly considered by every programming language community in the world to be *really* bad form to let GC clean up IO. There's tons of reasons for this:
>
> * GC may not run as soon as you like, causing you to hold IO resources too long (and under heavy load, potentially use up all descriptors for a process)
> * On some systems, old objects get promoted to heaps that are only rarely collected, resulting in them potentially never GCing (or only GCing extremely rarely)
> * There's no reason you *shouldn't* be able to close resources when they're no longer used. In this case, close any files opened for a give request once the request has been processed (async libraries
using those files should expect them to be closed and deal with that accordingly).
>
> Bug-finding tools for several languages flag this sort of behavior as a high-priority bug. Languages like Go, C#, and Java have or are adding features to help guarantee you never do this. It's pretty much universally frowned upon.
> When I tweeted about Rubyists leaving IO objects to be cleaned up or closed by GC, *everyone* agreed that it's a bug in the code, and that nobody should ever rely on GC to release File/IO resources.
>
> What more can I say? :)
>
> - Charlie