Skip to content
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

LocalExecutor without atomic/mutex structure overhead? #39

Closed
recatek opened this issue Mar 13, 2023 · 4 comments
Closed

LocalExecutor without atomic/mutex structure overhead? #39

recatek opened this issue Mar 13, 2023 · 4 comments

Comments

@recatek
Copy link

recatek commented Mar 13, 2023

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?

@notgull
Copy link
Member

notgull commented Mar 13, 2023

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.

@recatek
Copy link
Author

recatek commented Mar 13, 2023

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.

@notgull
Copy link
Member

notgull commented Mar 13, 2023

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.

@notgull
Copy link
Member

notgull commented Sep 28, 2023

It is now available here.

@notgull notgull closed this as completed Sep 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants