-
-
Notifications
You must be signed in to change notification settings - Fork 328
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
portforward: Improve API and support background task cancelation #854
Conversation
I'm realizing there's another issue with the port forward API: as far as I can tell, there's no way to take ownership of any of the |
Thanks for this! The portforward PR (#446) was sitting there for about a year, and we basically merged to get further feedback like this from users. You are welcome to propose changes however you like 😆 |
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. Just minor nit about #[from]
.
The `portforward` utility spawns a background task and returns a future that completes when the background task completes, but the spawned task's `JoinHandle` is discarded, so there's no way to cancel the background tasks before all of the port forwards complete. Furthermore, the `Portforwarder` types holds all `Port` instances and exposes no APIs to allow a caller to take ownership. This makes it difficult to work with a port stream. For example, it can't be moved onto a spawned task directly. Instead a user has to extract the streams (and errors) from the data structure. To try to simplify this API: * `Portforwarder` is updated to hold its streams and error handles in HashMaps keyed by port number. It is updated to expose `take_stream` and `take_error` methods so that callers can access either the I/O stream or the error handle by-numer. This is proposed to improve redability to avoid the unnecessary intermediate `Port` type. * `Portforwarder` is updated to hold a `tokio::task::JoinHandle` and it now exposes `abort` and `join` methods that interact with the background task. * `Portforward` no longer implements `Future` directly. This is done to reduce boilerplate code for what is now a very simple `async fn`. Signed-off-by: Oliver Gould <ver@buoyant.io>
ad46471
to
bbb20da
Compare
Signed-off-by: Oliver Gould <ver@buoyant.io>
80d0efa
to
c1806aa
Compare
@kazk Thanks for the quick review. I decided to propose a slightly larger API change after using the existing one. Let me know what you think. I'm happy to revert those changes, but I thought a shallower API was easier to follow. Let me know what you think! |
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.
This is much better :)
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.
wow, this is great. manages to both simplify the internals and the interface. very nice!
I'll rewrite |
The portforward utility spawns a background task and returns a future
that completes when the background task completes, but the spawned
task's
JoinHandle
is discarded, so there's no way to cancel thebackground tasks before all of the port forwards complete.
This change updates the
Portforwarder
type to hold theJoinHandle
and exposes a
Portforward::abort
method that cancels the spawned task.impl Future for Portforward
changes to await the background task'scompletion. A portforward::Error variant is added to expose task
failures.