| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772.
But comments was still kept absolute position. This commit aligns
comments with method definitions for consistency.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|\
| |
| | |
ActionDispatch::DebugLocks
|
| |
| |
| |
| |
| | |
Only intended to be enabled when in use; by necessity, it sits above any
reasonable access control.
|
|\ \
| |/
|/| |
Don't inherit from Concurrent::CountDownLatch
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
That class mangles .new, which interferes with our deprecation warning.
More generally, it suggests we shouldn't be subclassing without a very
good reason, and avoiding one allocation doesn't seem to meet that
criteria.
In passing, recommend the simpler Concurrent::Event for the common
count=1 case.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Awaken waiting threads even if the current thread (the previously
exclusive thread) hadn't taken a share lock.
This only happens in code that wasn't run within an executor, since that
always take an outermost share lock.
|
|/
|
|
| |
threads wake
|
| |
|
|
|
|
| |
A full write-preferring wait can lead to deadlock.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Specifically, clean up if the thread is killed while it's blocked
awaiting the lock... if we get killed on some other arbitrary line, the
result remains quite undefined.
|
| |
|
|
|
|
|
| |
If the thread isn't yet holding any form of lock, it has no claim over
what may / may not run while it's blocked.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
The concurrent-ruby gem is a toolset containing many concurrency
utilities. Many of these utilities include runtime-specific
optimizations when possible. Rather than clutter the Rails codebase with
concurrency utilities separate from the core task, such tools can be
superseded by similar tools in the more specialized gem. This commit
replaces `ActiveSupport::Concurrency::Latch` with
`Concurrent::CountDownLatch`, which is functionally equivalent.
|
| |
|
|
|
|
|
| |
We don't need to fully disable concurrent requests: just ensure that
loads are performed in isolation.
|
|
|