-
Notifications
You must be signed in to change notification settings - Fork 271
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
Have Buffer
use default executor
#121
Comments
I'll try to persist some of my thoughts from the Gitter about this change, and also how it interacts with #118. The proposed solution here is basically: struct Buffer<T, Request, Executor = DefaultExecutor>
where T: Service<Request>
{
executor: Executor,
worker: Option<Worker<T, Request>>,
// ...
} And then have fn poll_ready(...) -> ... {
if let Some(w) = self.worker.take() {
self.executor.spawn(w);
}
// ...
} With #118, the As for hiding the concrete task type that needs to be spawned using this approach, I'm not sure how the solution outlined there fixes issue I raise above? We basically already have the proposed wrapper type ( One alternative specifically for the And finally, isn't it a little sad for Overall, I think we should probably wait to make this change until after #118 lands. |
Buffer
requires an executor to spawn tasks. Currently, constructing a buffer requires an explicit executor to be passed in. Instead,Buffer::new
should default toDefaultExecutor
.Though, currently
Buffer::new
spawns the task eagerly innew
, but often times theBuffer
instance is created from outside of the runtime before, in which caseDefaultExecutor
won't work.There would be a new constructor fn
Buffer::new_with_executor
(though, the name might be improved) that takes an executor.Buffer
should also be updated to avoid exposing the concrete task type that needs to be spawned. We can opt for the strategy described here.The text was updated successfully, but these errors were encountered: