I'm not sure what you mean by 'forking the entire codebase'.
Even if Rails3, though, Rails supported multi-threaded request dispatching IF you had an app server stack that supported it.
In Rails3, you just had to explicitly turn it on with `config.threadsafe!`. Rails4 makes that the default, always on. That's really the only difference. There are at least a few concurrency-related bugs that have been fixed in Rails4 (I'm actually not sure how many), but even Rails3 was officially documented to do multi-threaded concurrent request dispatch just fine. (Actually even Rails 2.2 was!)
Finding a mature, reliable, well-documented app server stack that supports multi-threaded concurrent request dispatch may be harder. I can not say which do and which don't, but there are at least some potential options (including puma, which, if I understand it right, has multi-threaded concurrent request handling as part of it's original core use case).
I AM hoping that Rails4's "multi-threaded request dispatch on by default" situation will make the community pay more attention to this use case, result in more app servers supporting it first-class robustly, and any remaining bugs around concurrency being found and fixed. While Rails3 was documented to support this anyway (since Rails 2.2!), it has been mostly ignored by the community, for some reason.
(Sadly, while Passenger Enterprise 4 will support multi-threaded concurrent request dispatch, the Passenger folks are intentionally reserving this feature for Enterprise, the free one won't)
You can already run multiple instances of Unicorn. In fact, Unicorn is designed to be a multi-process app server. When running multiple (single-threaded) processes you don't need to be thread-safe. This is the process model that Mongrel and (open source) Phusion Passenger use as well.
But what you probably meant with "multiple instances" is "multiple threads". You can't do multiple threads with Unicorn, it's explicitly designed not to handle multithreading. Instead you should use an app server that's capable of multithreading, e.g. Phusion Passenger Enterprise 4 which is hybrid multi-process/multithreaded.
The Phusion Passenger Enterprise 4 multithreaded stack is already being tested or used in production by multiple organizations. We've been using it in production for months without problems.
Also, multithreading does not require Ruby 2.0. Ruby 1.9 works just fine.
ONLY if it's important to you that one process be able to run multiple threads on multiple CPU cores concurrently.
Even without this, there are MANY use cases where multi-threaded concurrent request dispatch makes a LOT of sense. For instance, the recent controversy about heroku routing, right?
With MRI or another interpreter with the GIL, you'd want to run one app process per CPU core -- but having each of those processes also do multi-threaded request handling can still even out latency (that is, avoid those awful ~95th+ percentile latencies in the heroku routing debacle), and increase overall throughput.
Especially if your app, like most but not all web apps, is more I/O bound than CPU bound (waiting on DB, disk, or external APIs).
Matz likes the fact that it Just Works and you can't accidentally have weirdness based on how your code runs. There aren't any plans to remove it at this time.
That's true, but I don't buy that argument: look at how fast everyone has updated their gems to be Ruby 2.0 compatible. The Ruby world likes running on the edge; if MRI forced us to consider thread safety, we'd learn about the issue much quicker as a community. Since we'd be forced to. ;)
Memory savings would be similar to when you used Phusion Passenger or Unicorn in combination with Ruby Enterprise Edition, which also has a copy-on-write friendly GC.
Funny thing about unicorn is, forking is core to its design. It may handle threading now, but when I last looked at its code fork() and traditional IPC via signals were core to its operation. Puma looks like the more thread-oriented choice these days.
