-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Remove duplication in serving with and without graceful shutdown #2803
Conversation
7047547
to
04b729e
Compare
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 great.
I just wonder if this couldn't go one step further and merge the Serve
and WithGracefulShutdown
into a single generic type. As it stands now, Serve<M, S>
is just WithGracefulShutdown<M, S, Pending>` so why not embrace it?
The only difference I know of is that with the current separation users cannot call with_graceful_shutdown
multiple times but I don't think that would be a problem.
Sure, could do that. But it feels like leaking implementation details into the public API, and I don't see the little bit of extra code as much of a problem. |
04b729e
to
c4de580
Compare
c4de580
to
f9308cf
Compare
f9308cf
to
3734152
Compare
I'm so confused about that error. Need to look into it, it's definitely no flake. |
I've taken a look. It's because the graceful shutdown serve code has additional tracing with So the easiest solutions are to pass the filter in Right now the helper is used from just this one test so it could also just be changed in place, but passing the filter in is a bit cleaner. |
The previous code would have not worked with the inner future migrating to a different OS thread within a work-stealing async executor.
Thanks for investigating! |
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.
Chaining the with_filter
call certainly looks better on the callsite than just passing it in, so this is good with me. Even if a custom future impl maybe is a bit complex solution for a test helper.
pub(crate) struct CaptureTracing<T, F> { | ||
f: F, | ||
filter: Option<Targets>, | ||
_phantom: PhantomData<fn() -> T>, |
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.
Just curious, why did you do this? I assume that since it's DeserializeOwned
, the T
will not be a reference so I don't see the point of going out of your way to make it contravariant. Am I missing something?
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.
fn(T)
would be contravariant, fn() -> T
is covariant. It's just good form for generic "output" parameters, doesn't actually matter here. See https://doc.rust-lang.org/nomicon/phantom-data.html#table-of-phantomdata-patterns for details.
Simpler implementation of the same idea from #2478, against latest
main
.