feat(swarm): Make executor for connection tasks explicit#3097
feat(swarm): Make executor for connection tasks explicit#3097mergify[bot] merged 40 commits intolibp2p:masterfrom
Conversation
thomaseizinger
left a comment
There was a problem hiding this comment.
Thanks for tackling this!
Please see inline comments :)
Co-authored-by: Thomas Eizinger <[email protected]>
|
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! |
thomaseizinger
left a comment
There was a problem hiding this comment.
Thanks! Some inline comments :)
Co-authored-by: Thomas Eizinger <[email protected]>
|
While we are on it: In the interest of #2166 we should add support for wasm bindgen futures. |
Co-authored-by: Thomas Eizinger <[email protected]>
…p2p into executor-aware-swarm
Oh that would be amazing actually! |
Co-authored-by: Thomas Eizinger <[email protected]>
|
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. |
thomaseizinger
left a comment
There was a problem hiding this comment.
API looks good to me apart from one breaking change :)
Co-authored-by: Thomas Eizinger <[email protected]>
|
Unless you want me to remove |
mxinden
left a comment
There was a problem hiding this comment.
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? 🙏 |
That's probably the happiest merge conflict I ever had to resolve. Finally QUIC!! |
mxinden
left a comment
There was a problem hiding this comment.
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.
Thank you for the great changelog entry.
|
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.
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.
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.
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.
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.
Trying to upgrade iroh to laster master and blocked on this :/
There was a problem hiding this comment.
Could you elaborate?
There was a problem hiding this comment.
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.
Can we just get rid of
SwarmBuilderinstead maybe? Is there a reason why any of the config values could not be set onSwarmitself?
@umgefahren Would you mind:
- sending a hotfix PR that makes these types public
- attempting to remove
SwarmBuilderaltogether 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.
Yes, I can do that (although I'm done for today)
…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.