| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
This basically reverts 8da30ad6be34339124ba4cb4e36aea260dda12bc
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
|
|
| |
Only intended to be enabled when in use; by necessity, it sits above any
reasonable access control.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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, 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.
|
| | |
|
| | |
|
|
|
We don't need to fully disable concurrent requests: just ensure that
loads are performed in isolation.
|
