Rails core - Mar 2013 - Is config.threadsafe! replaceable with config.allow_concurrency = true on Ruby 2.0?

In this
article<http://tenderlovemaking.com/2012/06/18/removing-config-threadsafe.html>Aaron
Patterson explains
config.threadsafe! effects.

Since that the not-threadsafe autoload bug is closed on Ruby
2.0<http://bugs.ruby-lang.org/issues/921>,
we can reconsider his observations:


  @preload_frameworks = true

The first option @preload_frameworks does pretty much what it says, it 
forces the Rails framework to be eagerly loaded on boot. When this option 
is *not* enabled, framework classes are loaded lazily via autoload. In 
multi-threaded environments, the framework needs to be eagerly loaded *
before* any threads are created because of thread safety issues with 
autoload <http://bugs.ruby-lang.org/issues/921>. We *know* that loading
the
framework isn’t threadsafe, so the strategy is to load it all up before any 
threads are ready to handle requests.

The bug is closed on Ruby 2.0, so @preload_frameworks should be safely set 
to false.


  @cache_classes      = true


The @cache_classes option controls whether or not classes get reloaded. 
Remember when you’re doing “TDD” in your application? You modify a 
controller, then reload the page to “test” it and see that things changed? 
Ya, that’s what this option controls. When this option is false, as in 
development, your classes will be reloaded when they are modified. Without 
this option, we wouldn’t be able to do our “F5DD” (yes, that’s F5 Driven 
Development).

In production, we know that classes aren’t going to be modified on the fly, 
so doing the work to figure out whether or not to reload classes is just 
wasting resources, so it makes sense to never reload class definitions.

This consideration is valid, but it is by default set to true in the 
production environment configuration file, so we can skip it.

  @dependency_loading = false

This option, @dependency_loading controls code loading when missing 
constants are encountered. For example, a controller references the Usermodel,
but the
User constant isn’t defined. In that case, if @dependency_loading is true, 
Rails will find the file that contains the User constant, and load that 
file. We already talked about how code loading is not thread safe, so the 
idea here is that we should load the framework, then load all user code, 
then *disable* dependency loading. Once dependency loading is disabled, 
framework code and app code should be loaded, and any missing constants 
will just raise an exception rather than attempt to load code.

We justify disabling this option in production because (as was mentioned 
earlier) code loading is not threadsafe, and we expect to have all code 
loaded before any threads can handle requests.

This is related to the same old bug
<http://bugs.ruby-lang.org/issues/921>, so we can set it to true.


  @allow_concurrency  = true

@allow_concurrency is my favorite option.  This option controls whether or not
the Rack::Lock middleware is used in your stack
<https://github.com/rails/rails/blob/568394659c3e56581c684df77c0cc0e6e264a99f/railties/lib/rails/application.rb#L263>.
Rack::Lock wraps a
mutex around your request
<https://github.com/rack/rack/blob/master/lib/rack/lock.rb>.  The idea
being that if you have code that is not
threadsafe, this mutex will prevent multiple threads from executing your
controller code at the same time.  When threadsafe! is set, this middleware is
removed, and controller code can be executed in parallel.

(google groups editing sucks) This is the only option which actually enables
Rails multithreading, so we set it to true, like Patterson wrote.

So, summing up:

  @preload_frameworks = false
  @cache_classes      = true
  @dependency_loading = true
  @allow_concurrency  = true

But the first three configurations are the default ones on the production
environment configuration file, so on Ruby 2.0 we can use:

  # Code is not reloaded between requests
  config.cache_classes = true
  # Enable threaded mode
  config.allow_concurrency = true

Isn''t it?

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.