|
|
|
|
|
# config.threadsafe!: what does it do?
|
|
|
|
|
|
# Let’s take a look at the threadsafe! method:
|
|
|
|
|
|
|
|
|
|
|
|
def threadsafe!
|
|
|
|
|
|
@preload_frameworks = true
|
|
|
|
|
|
@cache_classes = true
|
|
|
|
|
|
@dependency_loading = false
|
|
|
|
|
|
@allow_concurrency = true
|
|
|
|
|
|
self
|
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
|
|
# Calling this method sets four options in our app configuration. Let’s walk
|
|
|
|
|
|
# through each option and talk about what it does.
|
|
|
|
|
|
|
|
|
|
|
|
# Preloading Frameworks
|
|
|
|
|
|
# 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. 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.
|
|
|
|
|
|
|
|
|
|
|
|
# Caching classes
|
|
|
|
|
|
# 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.
|
|
|
|
|
|
|
|
|
|
|
|
# Dependency loading
|
|
|
|
|
|
# This option, @dependency_loading controls code loading when missing constants
|
|
|
|
|
|
# are encountered. For example, a controller references the User model, 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.
|
|
|
|
|
|
|
|
|
|
|
|
# Allowing concurrency
|
|
|
|
|
|
# @allow_concurrency option controls whether or not the Rack::Lock middleware
|
|
|
|
|
|
# is used in your stack. Rack::Lock wraps a mutex around your request. 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.
|
|
|
|
|
|
|
