DumpMempool/LoadMempool are not necessary for the kernel.
Noticed while working on instantiated logging.
I suppose these could have been left in on purpose, but I’m assuming it was probably just an oversight.
DumpMempool/LoadMempool are not necessary for the kernel.
Noticed while working on instantiated logging.
I suppose these could have been left in on purpose, but I’m assuming it was probably just an oversight.
DumpMempool/LoadMempool are not necessary for the kernel
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For detailed information about the code coverage, see the test coverage report.
See the guideline for information on the review process.
Type | Reviewers |
---|---|
ACK | TheCharlatan, stickies-v, glozow |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
126 using node::ApplyArgsManOptions;
127 using node::BlockManager;
128 using node::CacheSizes;
129 using node::CalculateCacheSizes;
130+using node::DumpMempool;
131+using node::LoadMempool;
node::DEFAULT_STOPATHEIGHT
.
I’ve got this on a branch that I’ll PR as soon as #30141 is merged: https://github.com/TheCharlatan/bitcoin/commits/kernelRmGlobals/ . I try to keep the open PRs limited to get more focused review.
Aha, I see.
I think this one is simple and self-contained enough to go in on its own unless you’re opposed.
I’ll ping you on these in the future to make sure you don’t already have them teed up.
Also, concept ACK on your next branch. Will give #30141 a final review and ACK to keep things moving.
Re-ACK f1478c05458562a9bef5c2ba43959d758e7b4745
I’ll ping you on these in the future to make sure you don’t already have them teed up.
No worries, it’s nice to see contributions from more developers, and if there is some redundant work every now and then, it just means it was reviewed already :)
ACK f1478c05458562a9bef5c2ba43959d758e7b4745
I think kernel should have an interface that (indirectly) allows users to dump/load mempool to/from disk (or elsewhere), but this mempool_persist
implementation seems too node opinionated to be included in kernel.
lgtm, iiuc you’d want #30141 merged before this one?
Mmh, I don’t think this was said anywhere? Looks like the two are not really related either.
lgtm, iiuc you’d want #30141 merged before this one?
Mmh, I don’t think this was said anywhere? Looks like the two are not really related either.
It seems they have a couple acks and conflict with each other? Was taking a guess based on #30344 (comment)
@glozow We both noticed this independently. @TheCharlatan Had it queued up as part of his next batch of changes (not yet PR’d), but I didn’t know that when I PR’d this one. He’s since agreed that it makes sense to merge this on its own.
#30141 is unrelated, he’s just waiting for that to be merged before PR’ing his next batch of kernel changes.
#30141 is unrelated, he’s just waiting for that to be merged before PR’ing his next batch of kernel changes.
I can see that they aren’t related, just trying to clarify which one to merge first because the PRs conflict. I figured this would be an ok place to ask that since it’s the same people. Apologies, I wasn’t trying to imply that they’re related at all, my previous comment was to provide an explanation for why I was asking which one to prioritize.