aboutsummaryrefslogtreecommitdiffstats
path: root/railties/test/generators/generators_test_helper.rb
diff options
context:
space:
mode:
authorXavier Noria <fxn@hashref.com>2014-09-18 22:35:19 +0200
committerXavier Noria <fxn@hashref.com>2014-09-18 23:04:08 +0200
commit112077c255879351edf4530791cc4bcc7bd4005b (patch)
treeb90e4038836769952ac35dbbfb02db0d6392a413 /railties/test/generators/generators_test_helper.rb
parent25f5af7f3f2695b0a8c33e2fce7fcd2bd630ece1 (diff)
downloadrails-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