net: keep mempool accept off tokio workers - #316
Merged
Conversation
added 3 commits
September 3, 2026 09:02
P2P Tx and Esplora POST /tx ran MempoolHub::accept_tx on tokio-rt-worker, taking inner RwLock across store UTXO lookups. All workers parked on that lock; the I/O driver never epoll_waited (mainnet freeze after tip). assert_not_reactor panics on a worker unless BlockingRegion is entered (tokio names spawn_blocking threads tokio-rt-worker too). accept_tx_async and Electrum/RPC/Esplora blocking closures enter the region.
inner.write() around Query get_coin serialized every P2P accept and blocked contains_wtxid on tokio workers. prepare_admit is now &self; orphans park under a short write. Relay map updates run after commit drops the graph lock.
Runtime::new() allowed 512 spawn_blocking threads. Cap at nCPU (min 4). Sync run_on_tip_accept panics on a tokio worker unless BlockingRegion is entered (RPC/generate). concurrency.md names reactor vs role vs pool.
rearden-grok
Bot
added
the
core-functional
fmt wants pub use reactor after rbitcoin_mempool. The async connect test called ensure_genesis (sync tip-accept wait) on a tokio worker.
This was referenced Sep 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Hours after tip, PID 1454645 froze with all 8
tokio-rt-workers infutex_wait.tip-acceptwas idle. Lasttip: perfshowedaccept_lock_us=1.78s/accept_utxo_us=1.39sthen the 5s timer died.P2P
NetworkMessage::TxcalledMempoolHub::accept_txon the session task.inner.write()covered store UTXO lookups. Other workers blocked on that lock (contains_wtxid, more accepts). Nobody parked the I/O driver.Same class as the earlier connect-on-tokio freeze, different function.
What
tip-accept, IBD pipeline,rbtc-sh-wb,rbtc-scripts-*) stay.assert_not_reactor: panics ifaccept_tx/ syncrun_on_tip_acceptwait run on a tokio worker withoutBlockingRegion. Tokio names both workers andspawn_blockingthreadstokio-rt-worker; the region is the allow flag.accept_tx_asyncfor P2P Tx and EsploraPOST /tx/POST /txs/package. Electrum/RPC blocking closures enter the region.contains_wtxidproceeds during slow UTXO. Orphans park under a short write. Relay maps update after commit drops the graph lock.max_blocking_threads = nCPU.max(4)instead of tokio’s 512.Not in this PR (follow-up): ArcSwap inv set / compact
list_liveoff reactor; makingJoinOnDrop'staticso Drop can detach on cancel (still waits for soundness of the borrowed job).Tests
cargo test -p rbitcoin-net --lib tx_relay::testscargo test -p rbitcoin-net --lib tip_accept::cargo test -p rbitcoin-node --lib blocking_pool