This is a diff of Marcos from #19197, which probably should have just been used at the time. After this change, and #21016, we’ll have no more global thread(Group)s hanging out in init.
Co-authored-by: MarcoFalke falke.marco@gmail.com
This is a diff of Marcos from #19197, which probably should have just been used at the time. After this change, and #21016, we’ll have no more global thread(Group)s hanging out in init.
Co-authored-by: MarcoFalke falke.marco@gmail.com
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
No conflicts as of last run.
This is a diff of Marcos from #19197, which probably should have just
been used at the time. After this change, and #21016, we'll have no more
global thread(Group)s hanging out in init.
Co-authored-by: MarcoFalke <falke.marco@gmail.com>
Concept ACK. @dongcarl Does moving block loading into the chainstate manager align with your goals ?
Edit: I personally think it should be factored out, but not necessarily to validation.cpp/h, we might want a separate “block storage handling” component where ThreadImport and such can move.
review ACK e3341dfaf7146f0f234d1a59007f008742360a7b
This is removing a “validation/blockimport” global from init.cpp. Happy to re-ACK if this is moved to a separate module as suggested by @laanwj
@dongcarl Does moving block loading into the chainstate manager align with your goals ?
I believe so. After a cursory look at this PR, I think the std::thread m_load_block
would probably eventually be moved into the ChainContext
struct I plan to introduce after g_chainman
is deglobalized, however, putting it in ChainstateManager
is the appropriate move for now!