From 7a42d8e4fe0cee5aad1f1fda674bc99f030ecd39 Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Wed, 7 Aug 2024 14:31:01 +0000 Subject: [PATCH] Minor doc tweaks to `MonitorHolder` 036c31c9d0b6a243fa33aa5f8d5148d2ca065617 introduced some minor doc changes but failed to imrpove the docs that is was changing fully which this does. Suggested by @tnull in review. --- lightning/src/chain/chainmonitor.rs | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lightning/src/chain/chainmonitor.rs b/lightning/src/chain/chainmonitor.rs index 57c673239..7e342f587 100644 --- a/lightning/src/chain/chainmonitor.rs +++ b/lightning/src/chain/chainmonitor.rs @@ -170,14 +170,15 @@ struct MonitorHolder { /// Note that this lock must be held from [`ChannelMonitor::update_monitor`] through to /// [`Persist::update_persisted_channel`] to prevent a race where we call /// [`Persist::update_persisted_channel`], the user returns a - /// [`ChannelMonitorUpdateStatus::InProgress`], and then calls channel_monitor_updated - /// immediately, racing our insertion of the pending update into the contained Vec. + /// [`ChannelMonitorUpdateStatus::InProgress`], and then calls + /// [`ChainMonitor::channel_monitor_updated`] immediately, racing our insertion of the pending + /// update into the contained Vec. /// /// This also avoids a race where we update a [`ChannelMonitor`], then while connecting a block /// persist a full [`ChannelMonitor`] prior to persisting the [`ChannelMonitorUpdate`]. This /// could cause users to have a full [`ChannelMonitor`] on disk as well as a /// [`ChannelMonitorUpdate`] which was already applied. While this isn't an issue for the - /// LDK-provided update-based [`Persist`], its somewhat surprising for users so we avoid it. + /// LDK-provided update-based [`Persist`], it is somewhat surprising for users so we avoid it. pending_monitor_updates: Mutex>, } -- 2.39.5