We currently have several threads in Bitcoin Core, and one of them is the scheduler. This scheduler takes care of DumpAddresses, MaybeResendWalletTxs, MaybeCompactWalletDB, CheckForStaleTipAndEvictPeers and ValidationInterface. It’s good idea to have a scheduler because it allows to avoid the memory overhead caused by having a dedicated thread per task.
It is currently unclear what are the expectations of the tasks the scheduler takes care of. For example, if there’s a way to externally fill the queue for seconds, one could influence wallet rebroadcast timings and deanonymize those transactions.
One issue I personally faced is integrating periodic DNS caches updates, a task which sometimes might take more than a minute, and there seem to be no trivial way to bound the runtime.
One way to make it work, and to make the time bound expectations more explicit: add a separate scheduler to take care of all non-immediate tasks, which may take longer than 5 seconds.
Besides DNS cache updates, this may be relevant to other features in the future, or allow making the existent features heavier. We can also move DumpAddresses there: it can’t be time-analyzed, but can possibly take long (if I/O is slow and a lot of entries), and is fine with waiting an extra minute. I believe it can also be relevant for the utxo snapshot creation from assumeutxo project?
Alternatively, we expand the existing single scheduler with a functionality which allows to set an upper bound on the runtime of tasks it executes, and/or switch between tasks (I don’t know how yet, but that should be doable).
I’m interested in your opinions!
