diff options
author | Xavier Noria <fxn@hashref.com> | 2014-09-18 22:35:19 +0200 |
---|---|---|
committer | Xavier Noria <fxn@hashref.com> | 2014-09-18 23:04:08 +0200 |
commit | 112077c255879351edf4530791cc4bcc7bd4005b (patch) | |
tree | b90e4038836769952ac35dbbfb02db0d6392a413 /railties/test/generators/generators_test_helper.rb | |
parent | 25f5af7f3f2695b0a8c33e2fce7fcd2bd630ece1 (diff) | |
download | rails-112077c255879351edf4530791cc4bcc7bd4005b.tar.gz rails-112077c255879351edf4530791cc4bcc7bd4005b.tar.bz2 rails-112077c255879351edf4530791cc4bcc7bd4005b.zip |
inject Rack::Lock if config.eager_load is false
If code is not eager loaded constants are loaded on demand. Constant
autoloading is not thread-safe, so if eager loading is not enabled
multi-threading should not be allowed.
This showed up in certain Capybara scenarios: Most Capybara drivers
other than Rack::Test need a web server. In particular, drivers for
JavaScript support. Capybara launches WEBrick in its own thread for
those but that per se is fine, because the spec thread and the server
thread are coordinated.
Problem comes if the page being served in the spec makes Ajax calls.
Those may hit WEBrick in parallel, and since WEBrick is multi-threaded
and allow_concurrency? returns true in the test environment before
this patch, threads are spawned to serve those parallel requests. On
the other hand, since eager_load is false by default in the test
environment, constants are not preloaded.
So the suite is autoloading constants in a multi-threaded set. That's
a receipt for paracetamol. The symptom is random obscure errors whose
messages point somehow to constant autoloading.
As a consequence of this fix for allow_concurrency? WEBrick in
Capybara scenarios no longer runs in multi-threaded mode.
Fixes #15089.
Diffstat (limited to 'railties/test/generators/generators_test_helper.rb')
0 files changed, 0 insertions, 0 deletions