Skip to content

Commit c1c133c

Browse files
authored
Merge pull request #3230 from TheBlueMatt/2024-08-old-doc-tweaks
Minor doc tweaks to `MonitorHolder`
2 parents fd8f4ac + 7a42d8e commit c1c133c

File tree

1 file changed

+4
-3
lines changed

1 file changed

+4
-3
lines changed

lightning/src/chain/chainmonitor.rs

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -170,14 +170,15 @@ struct MonitorHolder<ChannelSigner: EcdsaChannelSigner> {
170170
/// Note that this lock must be held from [`ChannelMonitor::update_monitor`] through to
171171
/// [`Persist::update_persisted_channel`] to prevent a race where we call
172172
/// [`Persist::update_persisted_channel`], the user returns a
173-
/// [`ChannelMonitorUpdateStatus::InProgress`], and then calls channel_monitor_updated
174-
/// immediately, racing our insertion of the pending update into the contained Vec.
173+
/// [`ChannelMonitorUpdateStatus::InProgress`], and then calls
174+
/// [`ChainMonitor::channel_monitor_updated`] immediately, racing our insertion of the pending
175+
/// update into the contained Vec.
175176
///
176177
/// This also avoids a race where we update a [`ChannelMonitor`], then while connecting a block
177178
/// persist a full [`ChannelMonitor`] prior to persisting the [`ChannelMonitorUpdate`]. This
178179
/// could cause users to have a full [`ChannelMonitor`] on disk as well as a
179180
/// [`ChannelMonitorUpdate`] which was already applied. While this isn't an issue for the
180-
/// LDK-provided update-based [`Persist`], its somewhat surprising for users so we avoid it.
181+
/// LDK-provided update-based [`Persist`], it is somewhat surprising for users so we avoid it.
181182
pending_monitor_updates: Mutex<Vec<u64>>,
182183
}
183184

0 commit comments

Comments
 (0)