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
Currently, LocalExecutor wraps Executor and uses Executor's State, which is designed to support multithreading and has the overhead of Mutex, Arc, ConcurrentQueue, and so on. It would be nice if there was a version of LocalExecutor that did not make this assumption and didn't have to pay for these structures in a strictly single-threaded context. Would this be possible to do now that rust-lang/rust#95985 is live in 1.68?
The text was updated successfully, but these errors were encountered:
While Context is now !Send/!Sync, Waker still is, so unless Context adds more fields related to local wakeups this still can't be really done. I've actually experimented with executors without these synchronization primitives in the past and it usually breaks down when you have to create a Waker for these tasks.
One idea might be to wrap everything in a reentrant mutex and use that for polling and wakeups.
Ah, I see. I know there's been discussion of a LocalWaker (see this pre-RFC) but it seems a ways off still. Looking into it, the synchronization primitives go pretty deep -- async-io's Reactor and Source, polling's Poller, and so on all use them. It's a tricky problem to untangle.
Something I've been writing is an async framework that uses !Send/!Sync primitives. The idea would probably stop at the async-io level, but such a framework would be usable in the single-thread use case.
Currently,
LocalExecutor
wrapsExecutor
and usesExecutor
'sState
, which is designed to support multithreading and has the overhead of Mutex, Arc, ConcurrentQueue, and so on. It would be nice if there was a version ofLocalExecutor
that did not make this assumption and didn't have to pay for these structures in a strictly single-threaded context. Would this be possible to do now that rust-lang/rust#95985 is live in 1.68?The text was updated successfully, but these errors were encountered: