It's worth pointing out that the 'thread-safe mode' is really "allow concurrent request dispatch" mode. It doesn't make Rails any more or less thread-safe -- the `thread_safe!` declaration is about you telling Rails that YOUR code is thread-safe, and thus it's safe for Rails to allow overlapping concurrent requests to be processed, instead of forcing requests to be processed serially. (Still requires an app server that can dispatch requests concurrently, for it to actually happen. Basically puma or passenger enterprise).
But yes, in Rails 4 that's the default mode, for Rails to allow concurrent overlapping requests. Meaning Rails 4 assumes by default that any local or gem code is thread-safe (may or may not be a safe assumption of course).
Both Rails 3.2 and Rails 4 (and really older Rails for quite some time) are intended and architected to be thread-safe. Modulo bugs. There were concurrency bugs in older versions for sure, which we know because so many of them have been fixed.
Rails 4 is. It turns on thread safe mode by default
> Are most gems?
Usually. I haven't had any problems with that myself
> For app code, presumably you'd have to avoid class variables and class instance variables
yeah thats quite a bit of it.