Skip to content

Commit bfd1128

Browse files
committed
[peer_handler] Take the peers lock before getting messages to send
Previously, if a user simultaneously called `PeerHandler::process_events()` from two threads, we'd race, which ended up sending messages out-of-order in the real world. Specifically, we first called `get_and_clear_pending_msg_events`, then take the `peers` lock and push the messages we got into the sending queue. Two threads may both get some set of messages to send, but then race each other into the `peers` lock and send the messages in random order. Because we already hold the `peers` lock when calling most message handler functions, we can simply take the lock before calling `get_and_clear_pending_msg_events`, solving the race.
1 parent f40e47c commit bfd1128

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

lightning/src/ln/peer_handler.rs

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1020,9 +1020,9 @@ impl<Descriptor: SocketDescriptor, CM: Deref, RM: Deref, L: Deref> PeerManager<D
10201020
// buffer by doing things like announcing channels on another node. We should be willing to
10211021
// drop optional-ish messages when send buffers get full!
10221022

1023+
let mut peers_lock = self.peers.lock().unwrap();
10231024
let mut events_generated = self.message_handler.chan_handler.get_and_clear_pending_msg_events();
10241025
events_generated.append(&mut self.message_handler.route_handler.get_and_clear_pending_msg_events());
1025-
let mut peers_lock = self.peers.lock().unwrap();
10261026
let peers = &mut *peers_lock;
10271027
for event in events_generated.drain(..) {
10281028
macro_rules! get_peer_for_forwarding {

0 commit comments

Comments
 (0)