does threadsafe and ruby 2.0 mean we can create multiple instances with something like unicorn without 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)
Try Jruby and Puma.
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.
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).
Phusion Passenger Enterprise 4 is also thread-oriented.