Is Radiant Thread-safe?

[Mark Reginald James]

Hi,

I can't find any declaration that Radiant is thread-safe. Can anyone
confirm? Every version, or just some?

Thanks.

[Jim Gay]

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.

--
Jim Gay
Saturn Flyer LLC
http://www.saturnflyer.com
571-403-0338

[Mark Reginald James]

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.

[Jim Gay]

On Wed, Aug 18, 2010 at 10:36 AM, Mark Reginald James

I've been meaning to move the current_user to a thread variable for a while.

The caching in Radiant is good and you can set a long expiration time
so often I only need one instance but that's not always the case.

If you have contributions to make Radiant better for rails'
multi-threaded mode, please fork the project and send some pull
requests.

[Mark Reginald James]

Jim Gay wrote:
> The caching in Radiant is good and you can set a long expiration time
> so often I only need one instance but that's not always the case.

Yes, I've found the caching really helps. But still, caching is not
used for either form posts or AJAX action. And if Ruby 1.9 is used,
other threads can interpret Radiant code while a thread is running OS
code to fetch a cached page from either disk or the in-memory disk
cache (in 1.8 other threads only run if a cache-read blocks because a
physical disk read is required).

> If you have contributions to make Radiant better for rails'
> multi-threaded mode, please fork the project and send some pull
> requests.

OK, I've sent you a pull request for the
UserActionObserver.current_user issue.

The only other potential thread-safe issue I can see is with
Rack::Cache. There's a note in their TODO.