-
Notifications
You must be signed in to change notification settings - Fork 280
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
Should Service require Clone? #11
Comments
I pushed an initial pass at a futures aware borrow cell. This would support the described use case nicely without imposing Code: futures-borrow And, adapting your example to use struct Endpoint {
redis: RedisService,
postgres: Borrow<PostgresService>,
}
impl Service for Endpoint {
// Associated types...
fn poll_ready(&mut self) -> Poll<(), Self::Error> {
try_ready!(self.redis.poll_ready());
// Checks if the `Borrow` is ready to be borrowed (not the actual underlying service
self.postgres.poll_ready()
}
fn call(&mut self) -> impl Future<Item = Response, Error = Error> {
let mut postgres = try!(self.postgres.try_borrow());
self.redis.call(redis_request).and_then(move |redis_response| {
postgres.ready()
.and_then(move |postgres| postgres.call(postgres_request))
}
} |
That's an interesting pattern. If I understand correctly, that service implementation is only allowing a single request to be in-flight at once, right? As a thought experiment, if you'd wrapped the postgres service in an |
Nevermind, that's not possible due to |
Is this still an unanswered question in peoples mind? This is a "no" or me, but #29 is still TBD. |
|
Context: #6. The question: should
Service
haveClone
as a supertrait?Does this mean you have an idea for a wrapper which takes any
Service
type and produces aService + Clone
type? If this works it at least alleviates my concern; users won't be totally out of luck if they need to clone a Service, they just need to apply this wrapper.So the model that I'm concerned about is this:
This results in ownership errors because the future needs to own the postgres handle. If the postgres handle isn't
Clone
, users simply can't write this code.If all they need to do is apply some wrapper around the handle, that's not as serious. But even then I suspect tower is going to get a similar reputation issue that tokio has had, so I'm wondering how much the performance impact of requiring every Service to build in its
Clone
aspect would actually be.The text was updated successfully, but these errors were encountered: