-
Notifications
You must be signed in to change notification settings - Fork 67
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
Benchmark and configurable pool #190
Comments
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.
|
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 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. |
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 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. |
@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 |
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
The text was updated successfully, but these errors were encountered: