1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
Commit graph

12 commits

Author SHA1 Message Date
Koichi ITO
ac717d65a3 [Active Support] rubocop -a --only Layout/EmptyLineAfterMagicComment 2017-07-11 13:12:32 +09:00
Kir Shatrov
72950568dd Use frozen-string-literal in ActiveSupport 2017-07-09 15:08:29 +03:00
Akira Matsuda
8da30ad6be [Active Support] require => require_relative 2017-07-01 18:38:04 +09:00
Xavier Noria
d66e7835be applies new string literal convention in activesupport/lib
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
2016-08-06 18:10:53 +02:00
Matthew Draper
04b4a0666b Provide a middleware to debug misbehaving locks
Only intended to be enabled when in use; by necessity, it sits above any
reasonable access control.
2016-06-10 19:33:38 +09:30
Matthew Draper
d3c9d808e3 Publish AS::Executor and AS::Reloader APIs
These should allow external code to run blocks of user code to do
"work", at a similar unit size to a web request, without needing to get
intimate with ActionDipatch.
2016-03-02 02:14:20 +10:30
Matthew Draper
3e4a69e52d Hand off the interlock to the new thread in AC::Live
Most importantly, the original request thread must yield its share lock
while waiting for the live thread to commit -- otherwise a request's
base and live threads can deadlock against each other.
2016-02-07 08:32:27 +10:30
Matthew Draper
f836630f8c After completing a load, give other threads a chance too
While we know no user code is running, we should do as much loading as
we can. That way, all the threads will then be able to resume running
user code together.

Otherwise, only the last arriving thread would get to do its load, and
would then return to userspace, leaving the others still blocked.
2016-02-02 03:21:03 +10:30
Matthew Draper
bd31aec9c3 We need stricter locking before we can unload
Specifically, the "loose upgrades" behaviour that allows us to obtain an
exclusive right to load things while other requests are in progress (but
waiting on the exclusive lock for themselves) prevents us from treating
load & unload interchangeably: new things appearing is fine, but they do
*not* expect previously-present constants to vanish.

We can still use loose upgrades for unloading -- once someone has
decided to unload, they don't really care if someone else gets there
first -- it just needs to be tracked separately.
2015-07-20 09:14:10 +09:30
Matthew Draper
0b93c48bbe Document ShareLock and the Interlock 2015-07-09 04:33:14 +09:30
Matthew Draper
383fed5f23 Rely on the load interlock for non-caching reloads, too 2015-07-09 03:31:30 +09:30
Matthew Draper
c37d47e308 Soften the lock requirements when eager_load is disabled
We don't need to fully disable concurrent requests: just ensure that
loads are performed in isolation.
2015-07-09 02:23:23 +09:30