Release monitor write lock in between update iterations #2528
Conversation
Codecov ReportPatch coverage:
❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more. Additional details and impacted files@@ Coverage Diff @@
## main #2528 +/- ##
==========================================
+ Coverage 90.56% 90.81% +0.24%
==========================================
Files 109 109
Lines 57304 59861 +2557
Branches 57304 59861 +2557
==========================================
+ Hits 51899 54362 +2463
- Misses 5405 5499 +94
☔ View full report in Codecov by Sentry. |
arik-so
force-pushed
the
arik/2023-08-2470-shorter-term-monitor-locks
branch
from
e9b3355 to
6237706
Compare
arik-so
force-pushed
the
arik/2023-08-2470-shorter-term-monitor-locks
branch
from
b6e7486 to
bb028a3
Compare
Previously, updating block data on a chain monitor would acquire a write lock on all of its associated channel monitors and not release it until the loop completed. Now, we instead acquire it on each iteration, fixing lightningdevkit#2470.
Releasing write locks in between monitor updates requires storing a set of cloned keys to iterate over. For efficiency purposes, that set of keys is an actual set, as opposed to array, which means that the iteration order may not be consistent. The test was relying on an event array index to access the revocation transaction. We change that to accessing a hash map keyed by the txid, fixing the test.
arik-so
force-pushed
the
arik/2023-08-2470-shorter-term-monitor-locks
branch
from
bb028a3 to
f80284c
Compare
| { | ||
| let funding_outpoints: HashSet<OutPoint> = HashSet::from_iter(self.monitors.read().unwrap().keys().cloned()); | ||
| for funding_outpoint in funding_outpoints.iter() { | ||
| let monitor_lock = self.monitors.read().unwrap(); |
There was a problem hiding this comment.
nit: rename monitor_lock -> monitors
| let funding_outpoints: HashSet<OutPoint> = HashSet::from_iter(self.monitors.read().unwrap().keys().cloned()); | ||
| for funding_outpoint in funding_outpoints.iter() { | ||
| let monitor_lock = self.monitors.read().unwrap(); | ||
| if let Some(monitor_state) = monitor_lock.get(funding_outpoint) { |
There was a problem hiding this comment.
nit: rename monitor_state -> monitor
| } | ||
| } | ||
|
|
||
| // do some followup cleanup if any funding outpoints were added in between iterations |
There was a problem hiding this comment.
"cleanup" doesn't sound right in this case.
Re-iterate if any funding outpoints were added in between write locked iterations above.
|
There are some hidden implications,
|
5 participants
Fixes #2470.