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 9470346f8529c391a265eb21cf95fcc8d348a008..266fd034da0867f7d5502bb7a4b8b80cf0eedaab 100644 (file)
--- 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