Nov 4, 2024

I updated the confirmation chaser to use a single thread high priority pool to chase validations and dispatch confirmability checks. [This caused me to notice that the validation chaser should also use an independent thread (not just independent strand on the network threadpool) for monitor and dispatch of validation jobs, either in high or normal priority as configured.] Confirmability still uses c++17 std::transform in the database query, which will project the three subqueries onto all available threads, on current thread priority. This will cause confirmation to stay close with validation (configured presently for normal thread priority). It will fall behind as it waits on validation gaps, which could be as high as the download window size (currently 50k blocks) but will catch up as gaps are filled. And of course excess CPU capacity will continue to fill in from the validator and downloader. Ideally we would want highest priority on confirm, lower on validate, and lower on download... but we really don't want to be below normal thread priority for any.