Hacker News Reader

Comment by amccloud | Hacker News Reader

One thing they forgot to mention (might be obvious) is that MRI under puma requires your app to be thread safe.

In practice, what does this mean for your typical Rails app?

Is Rails (3.2/4.0) thread safe? Are most gems? For app code, presumably you'd have to avoid class variables and class instance variables. Anything else?

> Is Rails (3.2/4.0) thread safe?

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.

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

Rails have been thread-safe for quite some time (yehuda says after fall 2008, so even before the whole merb merger thing).

(see http://yehudakatz.com/2010/08/14/threads-in-ruby-enough-alre... comment section)

Rails 3.2/4 are thread-safe -- or at least, they are architected and intended to be. So few people actually use Rails in a multi-threaded deploy environment -- and concurrency bugs can be so tricky -- that it would not surprise me if there are still some bugs hiding out.

There really is such a huge performance advantage to a multi-threaded deploy environment -- EVEN with MRI, for the typical I/O-bound webapp, although you'd definitely want both multi-process and multi-threaded under MRI GIL. (Both puma and passenger enterprise can give you this, although not passenger free).

I'm hoping people start to catch on to this, and multi-threaded app servers get more popular, making them more mature and feature-rich, and in turn flushing out remaining bugs in Rails, causing yet more interest in multi-threaded deploy environment, virtuous circle blah blah

I'm not sure why you qualified with MRI here. This is true on any runtime. Using Puma without threading (and thus requiring the code you run under it to be threadsafe) would be completely pointless.

I'm not trying to nitpick, I just don't want anyone getting the impression this isn't true under jruby or rubinius.

You're right. I only specified MRI because people often mistake that thread safety is handled by the GVL.

Reply on news.ycombinator.com