5 ms·

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

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?

trustfundbaby 12y ago
> 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.
- jrochkind1 12y ago
  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.
- xentronium 12y ago
  > 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-already/ http://yehudakatz.com/2010/08/14/threads-in-ruby-enough-alre... comment section)
jrochkind1 12y ago
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

trustfundbaby 12y ago

> 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.

jrochkind1 12y ago
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.
xentronium 12y ago
> 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-already/ http://yehudakatz.com/2010/08/14/threads-in-ruby-enough-alre... comment section)

jrochkind1 12y ago

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