May 11, 2021

@evoskuil Just curious, during full_node.chain().get_transaction() and .get_block() , is it ever the case that the async callback would be invoked *in the OS thread that this call is made*, i.e. **BEFORE** get_transaction/block() returns - Or instead, is the callback always run in one of LB’s worker threads? I was thinking that the optimal speed case would be dispatching the async callback within the self same OS thread as the get_transaction/block() call is made - e.g. in the situations where that transaction or block is already cached - here no work by LibBitcoin worker threads would be needed. This would be the highest possible logical speed possible. When work is passed from the calling thread to another OS thread, there is a tiny tiny bit of latency for the worker thread to wake up and the memory to move from core to core. Mostly unnoticeable though I guess if you make a billion tx/block requests in a *sequence*, that latency would add up. Anyhow this was mostly performance trivia. By the way separately, where in the code do I find how many worker threads full_node* actuall runs? My thought is, an SSD tends to have is it 32+ queue depth. When the memory mapping accesses the disk, the OS thread blocks. For this reason a full_node for maximum performace, I presume, should have at least 32 OS threads?