From: valentinewallace Date: Tue, 26 Apr 2022 17:02:29 +0000 (-0400) Subject: Merge pull request #1436 from TheBlueMatt/2022-04-event-process-try-lock X-Git-Tag: v0.0.107~55 X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=commitdiff_plain;h=72069bfc9d082d3d142cfa09dca2bf6e1f085710;hp=d1b984d8648aae56454bc4cf57c3119511b42886;p=rust-lightning Merge pull request #1436 from TheBlueMatt/2022-04-event-process-try-lock Reorder the BP loop to make manager persistence more reliable --- diff --git a/lightning-background-processor/src/lib.rs b/lightning-background-processor/src/lib.rs index 7a1512b7..e23737c0 100644 --- a/lightning-background-processor/src/lib.rs +++ b/lightning-background-processor/src/lib.rs @@ -203,10 +203,22 @@ impl BackgroundProcessor { let mut have_pruned = false; loop { - peer_manager.process_events(); // Note that this may block on ChannelManager's locking channel_manager.process_pending_events(&event_handler); chain_monitor.process_pending_events(&event_handler); + // Note that the PeerManager::process_events may block on ChannelManager's locks, + // hence it comes last here. When the ChannelManager finishes whatever it's doing, + // we want to ensure we get into `persist_manager` as quickly as we can, especially + // without running the normal event processing above and handing events to users. + // + // Specifically, on an *extremely* slow machine, we may see ChannelManager start + // processing a message effectively at any point during this loop. In order to + // minimize the time between such processing completing and persisting the updated + // ChannelManager, we want to minimize methods blocking on a ChannelManager + // generally, and as a fallback place such blocking only immediately before + // persistence. + peer_manager.process_events(); + // We wait up to 100ms, but track how long it takes to detect being put to sleep, // see `await_start`'s use below. let await_start = Instant::now();