f update comment and use 2xPING_TIMER again.

Author: TheBlueMatt

lightning-background-processor/src/lib.rs

@@ -223,9 +223,8 @@ impl BackgroundProcessor {
 				channel_manager.process_pending_events(&event_handler);
 				chain_monitor.process_pending_events(&event_handler);
 
-				// We wait up to 100ms, but on a mobile device without a ton of activity, if we get
-				// put in the background and paused, this is likely where it will happen, causing
-				// the wait time to be substantially longer.
+				// 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();
 				let updates_available =
 					channel_manager.await_persistable_update_timeout(Duration::from_millis(100));
@@ -246,14 +245,14 @@ impl BackgroundProcessor {
 					channel_manager.timer_tick_occurred();
 					last_freshness_call = Instant::now();
 				}
-				if await_time > Duration::from_secs(1) {
+				if await_time.as_secs() > 2 * PING_TIMER {
 					// On various platforms, we may be starved of CPU cycles for several reasons.
 					// E.g. on iOS, if we've been in the background, we will be entirely paused.
 					// Similarly, if we're on a desktop platform and the device has been asleep, we
 					// may not get any cycles.
 					// In any case, if we've been entirely paused for more than double our ping
 					// timer, we should have disconnected all sockets by now (and they're probably
-					// dead anyway), so disconnect them by calling `timer_tick_occurred()` twice.
+					// dead anyway).
 					// Note that we have to take care to not get here just because user event
 					// processing was slow at the top of the loop. For example, the sample client
 					// may call Bitcoin Core RPCs during event handling, which very often takes