-
Notifications
You must be signed in to change notification settings - Fork 42
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
Comments
There's some confusion in the async ecosystem over what an executor is.
For some reason reactors are sometimes called executors. Maybe because in |
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 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. |
Eh, I'd argue otherwise.
I think I'll raise an issue on the async book. |
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) |
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
?The text was updated successfully, but these errors were encountered: