Jim Gay wrote:
> On Wed, Jul 28, 2010 at 3:13 AM, Mark Reginald James <m...@bigpond.net.au> 
> wrote:
> > I can't find any declaration that Radiant is thread-safe. Can anyone
> > confirm? Every version, or just some?
> This isn't really a concern unless you are running it on JRuby. And
> we're not doing anything in the core that requires parallel execution.
> The only place where this might be a weakness in a true multi-threaded
> environment is that we set the current_user class variable on the
> UserActionObserver for catching who created and updated what.
> Each request into your application will be processed completely, so no
> second request will ever step in at some point and get the wrong
> current_user.
> It's not being built as an application that handles concurrent
> processing, so it's not surprising that there's little mention of
> thread safety. With a typical setup it just doesn't matter.

Thanks for the reply Jim.

A server runs much more efficiently when Rails is run multi-threaded,
even when using standard Ruby, and even when using standard Ruby 1.8.
While currently only JRuby can concurrently interpret Ruby code,
standard Ruby can still run a request in another thread when a request
does file I/O (Radiant::Cache) or network I/O (database, API, DRb).

Multi-threaded mode can serve many concurrent requests from one
Radiant process, instead of needing one handler process per concurrent
request, which wastes memory and thrashes CPU caches. How many Radiant
processes are you running for each of your apps?

Thanks for pointing to the issue with the setting of current_user.
This would indeed be a problem in multi-threaded Rails. It would have
to be either moved into the controller instance (which is per-
request), or thread variables used in the observer.

Reply via email to