Skip to content

Conversation

maflcko
Copy link
Member

@maflcko maflcko commented Sep 18, 2019

This changes the type of the entry time of txs into the mempool from int64_t to std::chrono::seconds.

The benefits:

  • Documents the type for developers
  • Type violations result in compile errors
  • After compilation, the two are equivalent (at no run time cost)

@cvengler
Copy link
Contributor

Concep ACK,
chrono is definitely better for time managment

@DrahtBot
Copy link
Contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #16851 (Continue relaying transactions after they expire from mapRelay by ajtowns)

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.

@ajtowns
Copy link
Contributor

ajtowns commented Sep 19, 2019

ConceptACK

I think LimitMemPoolSize() should have std::chrono::seconds age instead of unsigned long age, which means you can just pass in std::chrono::hours{gArgs.GetArg(...)}; makes it a bit tidier.

Having int64_t as_seconds(std::chrono::seconds t) { return t.count(); } seems like it would be better than using int64_t{xxx.count()} fwiw; that way if we change xxx's type either the conversion happens automatically if there's no loss of precision, or you get a compile time error.

MarcoFalke added 2 commits September 19, 2019 11:30
Also, remove the now unused "Mine a single block to get out of IBD".
This was fixed in commit 1111aec.
@maflcko maflcko force-pushed the 1909-mempoolEntryChrono branch from fa05d99 to fa18adc Compare September 19, 2019 15:49
@maflcko
Copy link
Member Author

maflcko commented Sep 19, 2019

Thx for the review. Took all suggestions by you.

@maflcko maflcko force-pushed the 1909-mempoolEntryChrono branch from fa18adc to faec689 Compare September 23, 2019 12:01
@ajtowns
Copy link
Contributor

ajtowns commented Sep 23, 2019

utACK faec689

@@ -1541,11 +1541,11 @@ void static ProcessGetData(CNode* pfrom, const CChainParams& chainparams, CConnm
if (mi != mapRelay.end()) {
connman->PushMessage(pfrom, msgMaker.Make(nSendFlags, NetMsgType::TX, *mi->second));
push = true;
} else if (pfrom->m_tx_relay->timeLastMempoolReq) {
} else if (pfrom->m_tx_relay->m_last_mempool_req.load().count()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not use count_seconds here, if it is preferred to inline .count() (according to the comment)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The member uses a magic value of 0 to indicate that the mempool was never requested. So this check isn't about time (in a specific type like seconds), but more about checking that any value exists.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, okay, I guess we'd really want a optional here some day instead of a magic value, but no need to do that here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry to chime in late -- would it make sense to use the std::chrono::duration::zero value here? I found count() to be unintuitive when I was looking at related code just now (but this std::chrono stuff is new to me so I'm still figuring out how to use it).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comparing it to zero would also work, but still be odd, as the code is written as if the member were an optional.

I think we can just stop treating it as optional (always assume the last mempool request time for peers was in year 1970). But that can be done in a follow up pull request.

@laanwj
Copy link
Member

laanwj commented Oct 2, 2019

ACK faec689

laanwj added a commit that referenced this pull request Oct 2, 2019
faec689 txmempool: Make entry time type-safe (std::chrono) (MarcoFalke)
faaa1f0 util: Add count_seconds time helper (MarcoFalke)
1111170 test: mempool entry time is persisted (MarcoFalke)

Pull request description:

  This changes the type of the entry time of txs into the mempool from `int64_t` to `std::chrono::seconds`.

  The benefits:
  * Documents the type for developers
  * Type violations result in compile errors
  * After compilation, the two are equivalent (at no run time cost)

ACKs for top commit:
  ajtowns:
    utACK faec689
  laanwj:
    ACK faec689

Tree-SHA512: d958e058755d1a1d54cef536a8b30a11cc502b7df0d6ecf84a0ab1d38bc8105a67668a99cd5087a444f6de2421238111c5fca133cdf8e2e2273cb12cb6957845
@laanwj laanwj merged commit faec689 into bitcoin:master Oct 2, 2019
@maflcko maflcko deleted the 1909-mempoolEntryChrono branch October 2, 2019 14:56
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Oct 2, 2019
faec689 txmempool: Make entry time type-safe (std::chrono) (MarcoFalke)
faaa1f0 util: Add count_seconds time helper (MarcoFalke)
1111170 test: mempool entry time is persisted (MarcoFalke)

Pull request description:

  This changes the type of the entry time of txs into the mempool from `int64_t` to `std::chrono::seconds`.

  The benefits:
  * Documents the type for developers
  * Type violations result in compile errors
  * After compilation, the two are equivalent (at no run time cost)

ACKs for top commit:
  ajtowns:
    utACK faec689
  laanwj:
    ACK faec689

Tree-SHA512: d958e058755d1a1d54cef536a8b30a11cc502b7df0d6ecf84a0ab1d38bc8105a67668a99cd5087a444f6de2421238111c5fca133cdf8e2e2273cb12cb6957845
deadalnix pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Jun 11, 2020
Summary:
Also, remove the now unused "Mine a single block to get out of IBD".
This was fixed in commit 1111aecbb5.

bitcoin/bitcoin@1111170

---

Depends on D6522

Partial backport of [[bitcoin/bitcoin#16908 | PR16908]]

Test Plan:
  test_runner.py mempool_persist

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D6523
deadalnix pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Jun 11, 2020
Summary:
bitcoin/bitcoin@faaa1f0

---

Depends on D6523

Partial backport of Core [[bitcoin/bitcoin#16908 | PR16908]]

Test Plan:
  ninja

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D6524
deadalnix pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Jun 11, 2020
Summary:
bitcoin/bitcoin@faec689

---

Depends on D6524

Concludes backport of Core [[bitcoin/bitcoin#16908 | PR16908]]

Test Plan:
  ninja check-all

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D6527
kwvg added a commit to kwvg/dash that referenced this pull request Jul 2, 2021
kwvg added a commit to kwvg/dash that referenced this pull request Jul 4, 2021
kwvg added a commit to kwvg/dash that referenced this pull request Jul 9, 2021
kwvg added a commit to kwvg/dash that referenced this pull request Jul 9, 2021
kwvg added a commit to kwvg/dash that referenced this pull request Jul 9, 2021
kwvg added a commit to kwvg/dash that referenced this pull request Jul 13, 2021
kwvg added a commit to kwvg/dash that referenced this pull request Jul 15, 2021
kwvg added a commit to kwvg/dash that referenced this pull request Jul 15, 2021
kwvg added a commit to kwvg/dash that referenced this pull request Jul 16, 2021
kwvg added a commit to kwvg/dash that referenced this pull request Aug 1, 2021
kwvg added a commit to kwvg/dash that referenced this pull request Aug 5, 2021
kwvg added a commit to kwvg/dash that referenced this pull request Aug 5, 2021
5tefan pushed a commit to 5tefan/dash that referenced this pull request Aug 12, 2021
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Dec 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants