You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A common pattern for blocking functions in Rust is to provide a _timeout variant, see rust-lang/rust#46316. However, this crate currently doesn't provide a way to interrupt blocking executions, which prevents it to be used in some workflows.
Here is the context of my main use case:
I've implemented a channel, and because it's a channel, the synchronization is naturally implemented using asynchronous code and primitives like AtomicWaker. However, I also needed to expose a synchronous API, with timeout/deadline capabilities. Because futures_executor::block_on didn't have a _timeout counterpart, I couldn't rely on it, and had to write the synchronous API (using thread::park and reimplementing AtomicWaker) myself.
This feature request would simplify things a lot, allowing me to fully delegate the synchronous implementation to the future_executor crate. (Performance may be a little bit worse, because of mandatory TLS access even if waker is not used, but the simplification should be worth it)
The text was updated successfully, but these errors were encountered:
A common pattern for blocking functions in Rust is to provide a
_timeout
variant, see rust-lang/rust#46316. However, this crate currently doesn't provide a way to interrupt blocking executions, which prevents it to be used in some workflows.Here is the context of my main use case:
I've implemented a channel, and because it's a channel, the synchronization is naturally implemented using asynchronous code and primitives like
AtomicWaker
. However, I also needed to expose a synchronous API, with timeout/deadline capabilities. Becausefutures_executor::block_on
didn't have a_timeout
counterpart, I couldn't rely on it, and had to write the synchronous API (usingthread::park
and reimplementingAtomicWaker
) myself.This feature request would simplify things a lot, allowing me to fully delegate the synchronous implementation to the
future_executor
crate. (Performance may be a little bit worse, because of mandatory TLS access even if waker is not used, but the simplification should be worth it)The text was updated successfully, but these errors were encountered: