-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
blockservice & exchange & bitswap: add non variadic NotifyNewBlock #242
base: main
Are you sure you want to change the base?
Conversation
5344f5d
to
4ff4bd2
Compare
Codecov ReportAttention: Patch coverage is
@@ Coverage Diff @@
## main #242 +/- ##
==========================================
- Coverage 60.36% 60.32% -0.04%
==========================================
Files 243 243
Lines 30953 30968 +15
==========================================
- Hits 18684 18682 -2
- Misses 10612 10626 +14
- Partials 1657 1660 +3
|
// NotifyNewBlock tells the exchange that a new block is available and can be served. | ||
NotifyNewBlock(ctx context.Context, blocks blocks.Block) error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any idea how widespread the dependency on this interface (and therefore the result of the breakage) is and the benefits of implementing this? For example, does this show up at all in profiles as a meaningful thing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think everyone relies either on the offline exchange (in order to wrap a blockstore) or bitswap. I don't belive many implementations exists, even in outside codebases.
Even if someone else implement this, just forwarding the call to NotifyNewBlocks
with a slice of 1, this is legal and easy to write.
This just aims to get over golang's lacking interprocedural virtual optimisations, it does not change any feature.
Most of our other APIs have both single and multiple versions for this reason (Put
vs PutMany
, GetBlock
vs GetBlocks
, ...).
@Jorropo : I don't see an issue linked to this PR. In the absence of this, can you share more on what's motivating this PR? |
@BigLep the PR and Commit bodies:
I can add the explanation about keeping it in-line with our other exchange APIs. This seems like a good usecase to try the idea @guseggert is cooking (some automated code migrator), that would add the |
4ff4bd2
to
3af3c29
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have strong opinions on this. It seems a relatively small change that can bring memory benefits - although arguably low. If others agree, I'm fine to have it merged.
FYSA: I rebased the PR and added the updated exchange for the gateway examples.
3af3c29
to
311cd1f
Compare
2023-04-06 conversation: will defer for now. Want to have clarity on how we handle breaking changes in Boxo. |
311cd1f
to
6a45c0e
Compare
This is ready to merge. Let's decide if we want this or not. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm? As noted in https://github.com/ipfs/boxo/pull/242/files#r1153577309 this follows existing convention from other places (Put
vs PutMany
, GetBlock
vs GetBlocks
etc), and simplifies code slightly. If someone has custom implementation, should be trivial to migrate.
@aschmahmann any concerns?
Variadicts in go are just syntactic sugar around passing a slice, that means all go memory reachability rules apply, this force the compiler to heap allocate the variadic slice for virtual call, because the implementation is allowed to leak the slice (and go's interprocedural optimisations do not cover virtuals). Passing a block without variadic will pass the itab either on the stack or decomposed through registers. Skipping having to allocate a slice.
73226d5
to
730b9bd
Compare
Variadicts in go are just syntactic sugar around passing a slice, that means all go memory reachability rules apply, this force the compiler to heap allocate the variadic slice for virtual call, because the implementation is allowed to leak the slice (and go's interprocedural optimisations do not cover virtuals).
Passing a block without variadic will pass the itab either on the stack or decomposed through registers. Skipping having to allocate a slice.