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

overgeneral documentation #77

Open
lolbinarycat opened this issue Jun 3, 2024 · 4 comments
Open

overgeneral documentation #77

lolbinarycat opened this issue Jun 3, 2024 · 4 comments

Comments

@lolbinarycat
Copy link

All executors have a queue that holds scheduled tasks:

this is not always true. a simple implications of block_on that loops until it receives Ready does not fulfill this. perhaps you meant to refer to a task named Exexutor?

@notgull
Copy link
Member

notgull commented Jun 3, 2024

There's some confusion in the async ecosystem over what an executor is.

  • smol::Executor is an executor. It schedules several tasks and multiplexes them across a set of threads.
  • smol::block_on is not an executor, it is a reactor. It runs a single task to completion.

For some reason reactors are sometimes called executors. Maybe because in tokio their executor is also their reactor.

@lolbinarycat
Copy link
Author

hmm, the async book isn't super clear about this. it says that executors are responsible for polling futures (which lines up with the std::task documentation, which seems to consider anything that calls Future::poll an executor), while reactors are responsible for async io and the like.

so i think that both would be considered an executor, while a reactor would be something like the blocking crate or tokio_uring.

nonetheless, the statement is still incorrect, as executors like futures::block_on don't have any internal queues, as they only support a single task. and i don't buy the idea that this is somehow a reactor, as it is specifically given as an example of an executor by the async book, and it does not implement any sort of async io.

@notgull
Copy link
Member

notgull commented Jun 4, 2024

while reactors are responsible for async io and the like.

Eh, I'd argue otherwise. futures_lite::block_on is a reactor in the same way () is a type. It runs a future and delivers events, it's just that the only event it delivers is waking up the future.

it is specifically given as an example of an executor by the async book, and it does not implement any sort of async io.

I think I'll raise an issue on the async book.

@lolbinarycat
Copy link
Author

even if "all executors can handle multiple tasks" is true, this is still overgeneral, since the executor could use some other non-queue datastructure like a red-black tree (such as the old linux CFS does)

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