From: Matthew Rheaume <mhr@lightspark.com>
Date: Tue, 5 Nov 2024 00:11:37 +0000 (-0800)
Subject: Updated docs on `PeerManager::process_events`.
X-Git-Url: http://git.bitcoin.ninja/?a=commitdiff_plain;h=9d071068a301ebcf612dd97769378de989d371c1;p=rust-lightning

Updated docs on `PeerManager::process_events`.

Try to make it a bit more clear that there are downsides to solely
relying on `lightning-net-tokio`, and it's still recommended to
occasionally call this function in a separate loop.
---

diff --git a/lightning/src/ln/peer_handler.rs b/lightning/src/ln/peer_handler.rs
index 9470346f8..266fd034d 100644
--- a/lightning/src/ln/peer_handler.rs
+++ b/lightning/src/ln/peer_handler.rs
@@ -2057,8 +2057,11 @@ impl<Descriptor: SocketDescriptor, CM: Deref, RM: Deref, OM: Deref, L: Deref, CM
 	/// May call [`send_data`] on [`SocketDescriptor`]s. Thus, be very careful with reentrancy
 	/// issues!
 	///
-	/// You don't have to call this function explicitly if you are using [`lightning-net-tokio`]
-	/// or one of the other clients provided in our language bindings.
+	/// This should be called any time we may have messages to send. It is automatically called by
+	/// [`lightning-net-tokio`] after processing incoming messages, and by
+	/// [`lightning-background-processor`] when channel state has changed. Therefore, If you are not
+	/// using both [`lightning-net-tokio`] and [`lightning-background-processor`], you may need to call
+	/// this function manually to prevent messages from being delayed.
 	///
 	/// Note that if there are any other calls to this function waiting on lock(s) this may return
 	/// without doing any work. All available events that need handling will be handled before the