Benchmark and configurable pool

[tisonkun]

Hi @notgull and all,

I like the design of async-io that it doesn't bind to any async runtime but has its own reactor to schedule IO tasks.

So I'm considering using async-io to replace some usage of tokio's io/net structs. But here are two concerns before the decision and your feedback would be valuable :D

1. Is there any benchmark shows the comparison to tokio? I wonder if there is significant regressions, tie, or outperformance.
2. Currently, async-io uses a global shared thread pool to schedule all the tasks. I wonder if it can be configurable. That said, most of the time a globally shared runtime is enough, but I may let the runtime dedicated to my code, not shared among all the crates use async-io.

[notgull]

1. Is there any benchmark shows the comparison to tokio? I wonder if there is significant regressions, tie, or outperformance.

None yet. It depends on the workload. The main difference between smol and tokio is that smol uses oneshot polling and tokio uses edge polling. As a general rule of thumb short-lived tasks will complete faster on one shot polling, but longer-lived tasks will complete faster with edge polling.

2. Currently, async-io uses a global shared thread pool to schedule all the tasks. I wonder if it can be configurable. That said, most of the time a globally shared runtime is enough, but I may let the runtime dedicated to my code, not shared among all the crates use async-io.

async-io doesn't do this, you may be thinking of [async-global-executor], which is largely async-std specific. In smol you typically create your own Executor and pass it to your code.

[tisonkun]

async-io doesn't do this, you may be thinking of [async-global-executor], which is largely async-std specific. In smol you typically create your own Executor and pass it to your code.

My intention may be about this global thread pool:

        thread::Builder::new()
            .name("async-io".to_string())
            .spawn(move || main_loop(parker))
            .expect("cannot spawn async-io thread");

This pool is shared among all the crates in the final binary. I wonder if making this pool associated to the reactor, and allowing users to pass their own reactor instance instead of always use the global Reactor::get a possible evolving direction.

async-executor works well and is one of the alternative scheduler I'd replace tokio in the context of this issue. But it's unrelated to this dedicated thread pool topic.

[notgull]

My apologies, I was confused. This isn't a thread pool; it's a single thread that acts as a fallback for when no other thread is running async_io::block_on.

I've considered adding configurable reactors in the past, but I've avoided implementing it because it adds a lot of complexity for very little real-life benefit. The reactor isn't very opinionated anyways, so there shouldn't be an issue with sharing it among multiple different packages.

[tisonkun]

@notgull Feedback received. I understand the situation here now.

You can keep it open for further improvement if anyone would spend time to allow dedicated Reactors.