recently I reported #33554, which was fixed by the introduction of interruptWait via #33575

then I noticed crashes for similar reasons (although unrelated to waitNext), which I explain in detail here: stratum-mining/sv2-apps#88 (comment)

TLDR: I was trying to do a getBlock while a submitSolution was happening at the same time, both against the same Bitcoin Core thread

this made me realize that regardless of whether the call is going to block for a long time (like waitNext), I simply cannot leave room for concurrent calls against the same Bitcoin Core thread

which feels a bit contradictory to what @ryanofsky suggested here: #33554 (comment)

More broadly, I think I'd try just having a c++ "waiter" thread dedicated to running waitNext calls, and a c++ "worker" thread to run all other IPC operations besides waitNext. The "waiter" thread should be mostly blocked monitoring mempool and network, and the "worker" thread should be available to do anything else you might need like fetching and submitting block data.

and it's making me re-evaluate some assumptions I had when I started stratum-mining/sv2-apps#59

overall, I'm getting to a place where I'm having to go great lengths in terms of defensive programming just to avoid crashing Bitcoin Core

I'm still evaluating the trade-offs of potential defensive strategies, namely:

• having synchronization primitives that avoid overlapping requests against the same Bitcoin Core thread
• instantiating multiple Bitcoin Core threads, one dedicated for each potentially concurrent request

but I digress... the main point I wanted to articulate here was: shouldn't Bitcoin Core simply not crash if two requests arrive for the same thread?

ideally, a naive client should simply be forced to wait a bit longer if they send concurrent requests against the same Bitcoin Core thread, instead of being forced to avoid doing this at all cost because it could cause havoc on the other side of the IPC connection