-
Notifications
You must be signed in to change notification settings - Fork 55
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
{.async: (raises).}
for MultistreamSelect
#1066
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,5 @@ | ||
# Nim-LibP2P | ||
# Copyright (c) 2023 Status Research & Development GmbH | ||
# Copyright (c) 2023-2024 Status Research & Development GmbH | ||
# Licensed under either of | ||
# * Apache License, version 2.0, ([LICENSE-APACHE](LICENSE-APACHE)) | ||
# * MIT license ([LICENSE-MIT](LICENSE-MIT)) | ||
|
@@ -701,30 +701,40 @@ | |
for id, addrs in g.parameters.directPeers: | ||
await g.addDirectPeer(id, addrs) | ||
|
||
method start*(g: GossipSub) {.async.} = | ||
method start*( | ||
g: GossipSub | ||
): Future[void] {.async: (raises: [CancelledError], raw: true).} = | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. why the raw here? can't see how it matters. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. not familiar enough to know if it matters, but it makes the flow more explicit. there is no async involved in this method, so if the transformation introduces more complex logic or increases compile time, rather opting out of it There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. makes it hard to read though - complexity is negligible in simple cases like this, specially since it's not part of any hot path There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yeah, that's true, the non-raw version is a bit simpler to read, but is a bit less clear about what's going on / as in, there is no async involved at all in the implementation, it's just a regular synchronous function. side note: one of the other PRs actually was triggered by switching some of the redirectors to anyway, will keep it in mind going forward and transform to can do another cleanup pass for readability after the raises annotations are done, depending on the outcome of the discussion. personally I'm also fine with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the thing with newFuture is that it opens up two avenues for "classic" bugs: returning nil on some code path and returning an accidentally unfinished future on some code path - it's risky shit, for a dumb start function. ie when reviewing, I had to spend time ascertaining this point (it would have been more clear btw had you put the newfuture call at the end of the function where it gets returned, instead of at the beginning because as is, there's too much unnecessary distance between construction and use). The most simple things are the most pleasurable to debate ;) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. True, haven't been bitten by those personally, but can see them happening relatively easily. It's a good point, generally, especially as it seems that the async transformation is not too costly for purely synchronous functions. |
||
let fut = newFuture[void]() | ||
fut.complete() | ||
|
||
trace "gossipsub start" | ||
|
||
if not g.heartbeatFut.isNil: | ||
warn "Starting gossipsub twice" | ||
return | ||
return fut | ||
|
||
g.heartbeatFut = g.heartbeat() | ||
g.scoringHeartbeatFut = g.scoringHeartbeat() | ||
g.directPeersLoop = g.maintainDirectPeers() | ||
g.started = true | ||
fut | ||
|
||
method stop*(g: GossipSub): Future[void] {.async: (raises: [], raw: true).} = | ||
let fut = newFuture[void]() | ||
fut.complete() | ||
|
||
method stop*(g: GossipSub) {.async.} = | ||
trace "gossipsub stop" | ||
g.started = false | ||
if g.heartbeatFut.isNil: | ||
warn "Stopping gossipsub without starting it" | ||
return | ||
return fut | ||
|
||
# stop heartbeat interval | ||
g.directPeersLoop.cancel() | ||
g.scoringHeartbeatFut.cancel() | ||
g.heartbeatFut.cancel() | ||
g.heartbeatFut = nil | ||
fut | ||
|
||
method initPubSub*(g: GossipSub) | ||
{.raises: [InitializationError].} = | ||
|
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.
not sure this is the right PR for it, but reraising underlying stream errors represents an abstraction leak - ie they should be caught and rebranded as multistreamerror really
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.
Agree, but the pattern of re-raising
LPStreamError
applies to quite large parts of the codebase, and the goal for now is to just document the reality with the{.async: (raises).}
, while fixing the obvious offenders ofraise (ref CatchableError)()
. Semantic changes should be separate.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.
Another precedent we have in
muxer.nim
where the procs currently raise{.async: (raises: [CancelledError, LPStreamError, MuxerError].}
, it's just how it's done today.