Rails Roundup: Rails 2.2 Will Be Threadsafe, ETags Support in Rails Edge

David Heinemeier Hansson recently mentioned that Rails 2.2 will fix a long standing problem with Rails: it's lack of thread safety. Charles Nutter went ahead and wrote up an explanation of what a thread safe Rails means:

[B]asically it means removing the single coarse-grained lock around every incoming request and replacing it with finer-grained locks around only those resources that need to be shared across threads. So for example, data structures within the logging subsystem have either been modified so they are not shared across threads, or locked appropriately to make sure two threads don't interfere with each other or render those data structures invalid or corrupt. Instead of a single database connection for a given Rails instance, there will be a pool of connections, allowing N database connections to be used by the M requests executing concurrently. It also means allowing requests to potentially execute without consuming a connection, so the number of live, active connections usually will be lower than the number of requests you can handle concurrently.

A look at a sample of commits and commit messages to the Rails Github repository shows what thread safety related work has been done recently:

• "MemoryStore is the only "unsafe" store. Make it threadsafe by default."
• "Added config.threadsafe! to toggle allow concurrency settings and disable the dependency loader" - check the comments for more information.
• "Maintain a seperate buffer for each thread"

Lack of thread safety in Rails required the use of groups of independend Ruby processes to be used to serve Rails applications, ie. using a shared nothing approach. A whole group of technologies and solutions were developed to handle the issue. Eg. Phusion Passenger uses a modified Ruby version with a Copy On Write friendly GC which allows sharing some loaded code across Ruby instances. It also made it easy to manage the group of processes. JRuby also allowed to lower the cost of multiple Rails instances by allowing to run multiple JRuby instances in the same JVM which allowed a certain amount of code sharing.

Even with thread safety, Rails sites will probably still require multiple Ruby instances to scale. One reason is Ruby's userspace thread system in 1.8. A single blocking I/O call will block all the threads in the interpreter. While non-blocking I/O is used in a lot of I/O libraries, the current Mysql adapter isn't one of them (actually, the problem stems from the C library not releasing the interpreter lock). Other DB adapters, however, do support non-blocking requests, eg. the Postgresql adapter.
Never_block is a library that makes is easy to use these adapters, although for the moment it requires Ruby 1.9.

Spreading the application across multiple interpreters also allows to make use of multicore systems despite the fact that pure userspace threads won't allow that.

Another new feature in Rails Edge is Simpler Conditional Get Support:

Conditional-gets are a facility of the HTTP spec that provide a way for web servers to tell browsers that the response to a GET request hasn’t changed since the last request and can be safely pulled from the browser cache.

Tim Bray provides a thorough introduction to ETags and what problem they solve:

But sometimes a single time-stamp isn’t enough information for a server to figure out whether the client needs a fresh copy of whatever it’s asking for.
ETags are for this situation. The way it works is, when a client sends you a GET, along with the result you send back an HTTP header like so:
ETag: "1cc044-172-3d9aee80"
Whatever goes between the quotation marks is a signature for the current state of the resource that’s been requested.