]> git.bitcoin.ninja Git - rust-lightning/commit
[block-sync] Don't hold client-cache lock while connecting 2024-07-stupid-locked-connect
authorMatt Corallo <git@bluematt.me>
Sun, 21 Jul 2024 23:29:19 +0000 (23:29 +0000)
committerMatt Corallo <git@bluematt.me>
Sun, 21 Jul 2024 23:29:19 +0000 (23:29 +0000)
commit7945af700da8a9d0f59c2c5f203217ca8c584ab2
tree51d9aa459fa96f7932e5c7b7933c109218c1bd01
parent9ce3dd5269fdfd4e44dcdeed8f4733a23ec9dc1a
[block-sync] Don't hold client-cache lock while connecting

`lightning-block-sync`'s REST and RPC clients both hold a cache for
a connected client to avoid the extra connection round-trip on each
request. Because only one client can be using a connection at once,
the connection is `take()`n out of an `Option` behind a `Mutex` and
if there isn't one present, we call `HttpClient::connect` to build
a new one.

However, this full logic is completed in one statement, causing a
client-cache lock to be held during `HttpClient::connect`. This
can turn into quite a bit of contention when using these clients as
gossip verifiers as we can create many requests back-to-back during
startup.

I noticed this as my node during startup only seemed to be
saturating one core and managed to get a backtrace that showed
several threads being blocked on this mutex when hitting a Bitcoin
Core node over REST that is on the same LAN, but not the same
machine.
lightning-block-sync/src/rest.rs
lightning-block-sync/src/rpc.rs