57 lines
2.9 KiB
Ruby
57 lines
2.9 KiB
Ruby
# 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.
|
||
|