blockservice & exchange & bitswap: add non variadic NotifyNewBlock #242
Conversation
Jorropo
force-pushed
the
notify-new-block
branch
3 times, most recently
from
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.
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.
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 |
hacdias
force-pushed
the
notify-new-block
branch
from
4ff4bd2
to
3af3c29
Compare
hacdias
force-pushed
the
notify-new-block
branch
from
3af3c29
to
311cd1f
Compare
|
2023-04-06 conversation: will defer for now. Want to have clarity on how we handle breaking changes in Boxo. |
gammazero
force-pushed
the
notify-new-block
branch
from
311cd1f
to
6a45c0e
Compare
gammazero
added
the
need/maintainers-input
|
This is ready to merge. Let's decide if we want this or not. |
There was a problem hiding this comment.
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.
gammazero
force-pushed
the
notify-new-block
branch
from
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.