-
Notifications
You must be signed in to change notification settings - Fork 964
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
feat(swarm): Make executor for connection tasks explicit #3097
Conversation
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.
Thanks for tackling this!
Please see inline comments :)
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
I can implement these changes, but I have a question: If we go back to trait objects here, which would be fine by me, that means I will remove all the genetics from the APIs it that's what you want. I'm asking because I read your issue a bit differently. |
l implemented the suggested changes. It results in a lot of warnings, but I will remove them if your happy with the api. |
Sorry if that was worded poorly! I tried to list multiple options there because I wasn't sure how things would turn out. Breaking type inference is definitely a no-no in regards to ergonomics so adding feature-gated functions seems like a better approach! |
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.
Thanks! Some inline comments :)
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
While we are on it: In the interest of #2166 we should add support for wasm bindgen futures. |
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
…p2p into executor-aware-swarm
Oh that would be amazing actually! |
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Let me know as soon as your fine with the changes made. I will then start the process of replacing all usages of the deprecated API. |
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.
API looks good to me apart from one breaking change :)
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Unless you want me to remove |
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.
Great work. Happy for this footgun to soon be gone.
@umgefahren could you please also create a pull request removing the deprecated methods? Once this is released we can then merge that second pull request.
This pull request has merge conflicts. Could you please resolve them @umgefahren? 🙏 |
Co-authored-by: Max Inden <mail@max-inden.de>
That's probably the happiest merge conflict I ever had to resolve. Finally QUIC!! |
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.
Follow up on inline
discussion. Otherwise looks good to me.
- Feature-gate `NetworkBehaviour` macro behind `macros` feature flag. See [PR 3055]. | ||
|
||
- Make executor in Swarm constructor explicit. See [PR 3097]. |
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.
Thank you for the great changelog entry.
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.
Thanks :)
Again, thanks @umgefahren for the help! |
(I am sure many future users not falling into this trap will be very happy (unknowingly).) |
|
||
#[cfg(feature = "tokio")] | ||
#[derive(Default, Debug, Clone, Copy)] | ||
pub(crate) struct TokioExecutor; |
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.
Why not expose TokioExecutor
and AsyncStdExecutor
? Folks that want to specify configs, e.g. dial_concurrency_factor
need to use the SwarmBuilder
. Instead of implementing Executor
on their custom type wrapping e.g. the async-std
executor, they could just reuse our implementation. Thoughts @umgefahren and @thomaseizinger?
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.
Yes, I think you are right. If Thomas agrees I can open a PR real quick changing that and adding some documentation.
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.
Alternatively, we could add the same set of with_
APIs.
I am okay either way. (I thought we had two layers of with_
APIs)
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.
Can we just get rid of SwarmBuilder
instead maybe? Is there a reason why any of the config values could not be set on Swarm
itself?
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.
Trying to upgrade iroh to laster master
and blocked on this :/
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.
Could you elaborate?
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 nedd the SwarmBuilder and have to reimplement the Executor trait by copy pasting the one in here, to use tokio.
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.
Can we just get rid of
SwarmBuilder
instead maybe? Is there a reason why any of the config values could not be set onSwarm
itself?
@umgefahren Would you mind:
- sending a hotfix PR that makes these types public
- attempting to remove
SwarmBuilder
altogether by moving the current "builder" functions directly ontoSwarm
LMK if you are not keen for the latter, then I'll try myself :)
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.
Yes, I can do that (although I'm done for today)
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.
Done #3155
…warmBuilder (#3155) Addresses issues raised here: #3097 (comment)
With #3097, subscribing to the floodsub topic in `examples/chat-tokio.rs` was removed. I assume this was unintentional (cc @umgefahren), so this PR adds it back.
Previously, the executor for connection tasks silently defaulted to a `futures::executor::ThreadPool`. This causes issues such as libp2p#2230. With this patch, we force the user to choose, which executor they want to run the connection tasks on which results in overall simpler API with less footguns. Closes libp2p#3068.
Description
Previously, the executor for connection tasks silently defaulted to a
futures::executor::ThreadPool
. This causes issues such as #2230.With this patch, we force the user to choose, which executor they want to run the connection tasks on which results in overall simpler API with less footguns.
Closes #3068.
Links to any relevant issues
Open Questions
Change checklist
I will add a changelog entry once it's clear how broad the changes are.