[carllerche]

Tokio is about being flexible (true today, even more true in the upcoming release). It is more about set of primitives that you can assemble in a way that fits your needs. You can structure the concurrency of your application however you want.

So...

> High I/O systems usually spawn multiple reactors, e.g. one reactor per CPU core.

Depends on what you are calling multiple reactors. If you mean a loop that responds to events and run tasks, then yes. For example, you can plug in [this](http://github.com/carllerche/futures-pool) as the task executor and get a multi threaded, work stealing, scheduler.

Or, maybe you are talking about OS level selectors (epoll), in which case you are going to run up against OS limitations.

[Const-me]

> you are talking about OS level selectors (epoll), in which case you are going to run up against OS limitations.

Yes, about them, but I’m not sure what OS limitations do you mean?

For Windows, it works fine from the very first NT 3.51 version of IOCP.

For Linux it indeed didn’t work in the very first version of epoll, but they fixed that adding EPOLLONESHOT flag, and recently EPOLLEXCLUSIVE flag for accept(), allowing to implement proper scaling of IO readiness notifications across multiple CPU cores.

[carllerche]

You can get this working with Tokio if you know what you are doing.

However, I personally advise against it as I have found that deferring to the OS for scheduling results in poor thread affinity (your state gets bounced around threads unnecessarily).

You generally get better throughput by either running multiple fully isolated reactors (the seastar approach) or running a single reactor which only flags tasks as ready to be executed, and then use a work stealing thread pool to do the actual execution.

Both of these structures are easy to achieve with Tokio.