mirror of
https://github.com/lightningdevkit/rust-lightning.git
synced 2025-02-27 08:28:49 +01:00
0c034e9a82
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 |
||
|---|---|---|
| .. | ||
| chan_utils.rs | ||
| chanmon_update_fail_tests.rs | ||
| channel.rs | ||
| channelmanager.rs | ||
| features.rs | ||
| functional_test_utils.rs | ||
| functional_tests.rs | ||
| inbound_payment.rs | ||
| mod.rs | ||
| monitor_tests.rs | ||
| msgs.rs | ||
| onion_route_tests.rs | ||
| onion_utils.rs | ||
| outbound_payment.rs | ||
| payment_tests.rs | ||
| peer_channel_encryptor.rs | ||
| peer_handler.rs | ||
| priv_short_conf_tests.rs | ||
| reload_tests.rs | ||
| reorg_tests.rs | ||
| script.rs | ||
| shutdown_tests.rs | ||
| wire.rs | ||