Matt Corallo a731efcb68 Process messages with only the top-level read lock held ... Users are required to only ever call `read_event` serially per-peer, thus we actually don't need any locks while we're processing messages - we can only be processing messages in one thread per-peer. That said, we do need to ensure that another thread doesn't disconnect the peer we're processing messages for, as that could result in a peer_disconencted call while we're processing a message for the same peer - somewhat nonsensical. This significantly improves parallelism especially during gossip processing as it avoids waiting on the entire set of individual peer locks to forward a gossip message while several other threads are validating gossip messages with their individual peer locks held.		2022-05-10 23:40:20 +00:00
..
chain	Expand chain::Listen trivially to accept filtered block data	2022-04-26 19:14:19 +00:00
ln	Process messages with only the top-level read lock held	2022-05-10 23:40:20 +00:00
routing	Provide a utility to log the ProbabilisticScorer's contents	2022-05-02 20:00:44 +00:00
util	Merge pull request #1444 from ViktorTigerstrom/2022-04-use-counterparty-htlc-max-for-chan-updates	2022-05-03 22:44:26 +00:00
debug_sync.rs	Use the term "lock" for Mutex/RwLock instead of "mutex"	2022-03-18 18:54:27 +00:00
lib.rs	Generate docs with features for docs.rs	2022-02-18 15:38:31 -06:00
sync.rs	Implement dummy Mutex, Condvar and RwLock	2021-07-20 20:59:18 +02:00