]> git.bitcoin.ninja Git - rust-lightning/commit
Never block a thread on the `PeerManager` event handling lock 2023-05-event-deadlock
authorMatt Corallo <git@bluematt.me>
Tue, 9 May 2023 00:30:33 +0000 (00:30 +0000)
committerMatt Corallo <git@bluematt.me>
Wed, 24 May 2023 02:39:37 +0000 (02:39 +0000)
commit0c034e9a82e4339fb32af9da63832ac2a64abb0b
tree65a8b9b6984fa1de8a0f5c5bf352e2ddb382c0b9
parent0ecb4b093ac1134cbf06275cc48dd79ef7524774
Never block a thread on the `PeerManager` event handling lock

If thre's a thread currently handling `PeerManager` events, the
next thread which attempts to handle events will block on the first
and then handle events after the first completes. (later threads
will return immediately to avoid blocking more than one thread).

This works fine as long as the user has a spare thread to leave
blocked, but if they don't (e.g. are running with a single-threaded
tokio runtime) this can lead to a full deadlock.

Instead, here, we never block waiting on another event processing
thread, returning immediately after signaling that the first thread
should start over once its complete to ensure all events are
handled.

While this could lead to starvation as we cause one thread to go
around and around and around again, the risk of that should be
relatively low as event handling should be pretty quick, and it's
certainly better than deadlocking.

Fixes https://github.com/lightningdevkit/rapid-gossip-sync-server/issues/32

Atomic lock simplification suggestion from @andrei-21
lightning/src/ln/peer_handler.rs
lightning/src/util/test_utils.rs