Is your feature request related to a problem? Please describe.
The creation of tokio::timeout might panic if no time driver is available/configured/enabled. This is decided at runtime creation time. Unfortunately, once created, it is impossible to know from a Handle that a runtime has a time driver or not. As a library, or in any setup that is generic over a tokio runtime (e.g. when multiple configurations are possible), there's no way to know in advance if we can use a timeout or if this will panic. I'd like to return a custom error when timeouts aren't available instead of panicking.
Describe the solution you'd like
Add a has_time_driver(&self) -> bool on tokio::runtime::Handle. A quick glance at the code seems to indicate this would be trivial: a multithread Handle has a driver handle, which has a timer handle, the latter being an Option. So it would amount to something like handle.driver.timer_driver.is_some() (I probably don't get the fields right exactly).
I'm eager to implement it if the maintainers think it's a reasonable addition.
Describe alternatives you've considered
The current working alternative is to use catch_unwind upon timer creation, but it's heavy, doesn't work with panic=abort, and it's fragile (we either catch unrelated panics or rely on hacks like matching the error message).
Is your feature request related to a problem? Please describe.
The creation of
tokio::timeoutmight panic if no time driver is available/configured/enabled. This is decided at runtime creation time. Unfortunately, once created, it is impossible to know from aHandlethat a runtime has a time driver or not. As a library, or in any setup that is generic over a tokio runtime (e.g. when multiple configurations are possible), there's no way to know in advance if we can use a timeout or if this will panic. I'd like to return a custom error when timeouts aren't available instead of panicking.Describe the solution you'd like
Add a
has_time_driver(&self) -> boolontokio::runtime::Handle. A quick glance at the code seems to indicate this would be trivial: a multithreadHandlehas a driver handle, which has a timer handle, the latter being anOption. So it would amount to something likehandle.driver.timer_driver.is_some()(I probably don't get the fields right exactly).I'm eager to implement it if the maintainers think it's a reasonable addition.
Describe alternatives you've considered
The current working alternative is to use
catch_unwindupon timer creation, but it's heavy, doesn't work with panic=abort, and it's fragile (we either catch unrelated panics or rely on hacks like matching the error message).