Is block_on an executor?

[notgull]

In general, but also in this book, I've heard the word "executor" refer to what I believe are two different concepts:

• A queue of tasks scheduled to be ran across a set of threads (I would argue this is an executor, and smol::Executor is a good example of this).
• A system that runs one single task to completion. For example, smol::future::block_on.

I think these are two different concepts, but they're often both referred to as "executors". Executor is not able to poll a future to completion on its own; it requires a top-level block_on for that. On the other hand, block_on on its own can only poll one future to completion.

Internally I've referred to the latter case (block_on) as a "reactor"; however it seems this is incorrect. async_io::block_on is fairly certainly a reactor, since it handles I/O events and timers.

However, futures_lite::block_on is in a gray area here. It handles no I/O events, it just polls the future to completion. I would argue that this is a reactor in the same way that () is a type.

I'm wondering if the book can be updated to clarify the differences here.

[notgull]

cc smol-rs/async-task#77

[lolbinarycat]

another important thing to consider is crates that provide futures for io, and launch a background thread in order to Wake those futures, notifying the executor when they can make progress, but do not provide any way of polling those futures.

in short, there are two parts:

1. the executor, which calls Future::poll (possibly just in a loop, possibly with some scheduling logic)
2. some sort of background thread that calls Waker::wake when a future can make progress (is this the reactor?)

note the 2 is actually optional, a simple future can just call Waker::wake() immediatly before returning Poll::Pending. the second thing defiantly needs a name though.

[lolbinarycat]

my interpretation (mostly informed by reading std::thread) is as follows:

1. if it calls Future::poll, it's an executor
2. if it calls Waker::wake after a future returns Pending, it's a reactor
3. if it does both, then it is both

although the docs are a bit unclear, so i'm unsure if this is the intended interpretation. adding a Glossary section to the async book would probably help.

[lolbinarycat]

@lbernick you wrote the relevant paragraph, mind weighing in on this?

[lbernick]

Sorry @lolbinarycat, I haven't worked on async rust in a few years so I don't think I'm the best person to weigh in here.

[lolbinarycat]

i'm just asking what you meant when you wrote that words

i'm really not sure who else could weigh in on this.. i guess it becomes an issue of prescriptivism vs descriptivism.. i guess a survey of how the words are used could help, but that's a lot of work.