Anthony

@seanmonstar thank you for your answer. Make sense if you are not planning a major bump then my proposal won't fit. What is this possible alternative you are talking about?...

Ah! Sorry 😀 misunderstanding, unfortunately as long as one construct an Instant then it relies on the system. I don't see how we could avoid it unfortunately. We will probably...

We do rely on h2 keep-alives

But yeah, in case one do not need timeouts hyper don't schedule it. One way would have been to remove the sleep_until from hyper and only rely on sleep. That...

Hey @seanmonstar, I am re-opening this after thinking about it a bit more... What do you think about this backward compatible compatible proposal? ```rust use std::{pin::Pin, sync::Arc, time::Duration}; trait Sleep...

Sorry to ping @seanmonstar but I have some free time I could use to work on it at the moment hence I'd like to know if the overall idea looks...

Hi, thanks for the feedback. As it seems that the idea makes some sense at least, I will write a PR for it. It definitely needs to be polished and...

@arielb1 well, std::time::instant or tokio one makes a lot of assumption on the system side (which clock is used for instance) and maybe you want a single centralized clock (do...

@arielb1 it's incorrect, some clocks take into account sleep time some other does not (boottime vs monotonic https://man7.org/linux/man-pages/man3/clock_gettime.3.html). It's not only the epoch that is important in some cases.

That's a very small subnet of use cases unfortunately. I believe that hyper should be as portable, fast, and accurate as possible