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

24 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
Matthew Draper
87b3e226d6 Revert "Merge pull request #29540 from kirs/rubocop-frozen-string"
This reverts commit 3420a14590, reversing
changes made to afb66a5a59.
2017-07-02 02:15:17 +09:30
Kir Shatrov
cfade1ec7e Enforce frozen string in Rubocop 2017-07-01 02:11:03 +03:00
Ryuta Kamizono
3464cd5c28 Fix broken comments indentation caused by rubocop auto-correct [ci skip]
All indentation was normalized by rubocop auto-correct at 80e66cc4d9.
But comments was still kept absolute position. This commit aligns
comments with method definitions for consistency.
2016-09-14 18:26:32 +09:00
Ryuta Kamizono
762e3f05f3 Add Style/EmptyLines in .rubocop.yml and remove extra empty lines 2016-08-07 17:50:59 +09:00
Xavier Noria
80e66cc4d9 normalizes indentation and whitespace across the project 2016-08-06 20:16:27 +02: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
Jeremy Daer
65b6496ee4
Share lock: more accurate livelock fix for aa598f4
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.
2016-04-24 10:14:53 -07:00
Jeremy Daer
aa598f4f39
Share lock: avoid livelock due to exclusive thread sleeping before waiting threads wake 2016-04-23 15:19:25 -07:00
Matthew Draper
11579b8306 Manual yield doesn't block new shares 2016-02-08 05:30:53 +10:30
Matthew Draper
d2c671e3cf Eagerly reacquire when start_sharing is nested inside yield_shares
A full write-preferring wait can lead to deadlock.
2016-02-08 00:36:21 +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
f02bd2a92c While new sharers are blocked, an existing sharer remains re-entrant 2016-02-02 03:21:03 +10:30
Matthew Draper
aeb58ab704 Block new share attempts if there's an exclusive waiter 2016-02-02 03:21:03 +10:30
Matthew Draper
e9020ac431 Handle thread death during lock acquisition
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.
2015-07-21 12:03:38 +09:30
Matthew Draper
4c54b2a9a0 Adjust expectations around purpose/compatibility options 2015-07-21 12:03:38 +09:30
Matthew Draper
649d8173c3 Order of execution is only guaranteed if upgrading
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.
2015-07-21 08:50:50 +09:30
thedarkone
b3d78e8c23 Fix ShareLock issues. 2015-07-20 19:01:15 +02:00
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
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