5 ms·

Seriously, with async you can just trash all your code because it will block your async event loop. So you have to rewrite every single library and network cli

by fooyc 10y ago

Seriously, with async you can just trash all your code because it will block your async event loop. So you have to rewrite every single library and network client in asynchronous mode.

akiselev 10y ago
You don't have to rewrite the (vast) majority of crates to be asynchronous because almost all of them can run from a thread pool with zero problems. Worst case scenario, you spawn a new OS thread and return a future which integrates very well with Tokio. Since it's built on top of futures-rs it will play nicely with other asynchronous crates and wrapping a synchronous library is much easier than rewriting it. It would be great to have every I/O library use OS specific polling mechanisms but that places a significant burden on library developers to not only know their domain, but have experience with each platforms quirks and limitations.
- fooyc 10y ago
  > all of them can run from a thread pool with zero problems Until you exhaust the thread pool, in which case everything relying on the thread pool will be much longer than usual to complete. Nodejs does this for name resolving, and it's a nightmare. Basically, with the default pool of 4 threads, it suffices of 4 slow resolves to DoS everything that needs to do a name resolve in the same process. I hope that Rust will not have the same problem when mixing async and thread pools. If the thread pool is not limited in size, you avoid this problem, but you lose all the benefits of async.
  - amaranth 10y ago
    > If the thread pool is not limited in size, you avoid this problem, but you lose all the benefits of async. You can't have both: either you have a limited pool and can block it on long running tasks or you don't and can wind up with a large number of threads. Go currently doesn't give you this choice and you're limited by whatever you set GOMAXPROCS to before you start your program. If you have GOMAXPROCS set to 4 and you have 4 goroutines that take a long time (not waiting for IO) you've blocked the ability to do any other work. This isn't entirely true of course because they have a runtime in-process scheduler (which adds more overhead) but you could easily avoid this particular problem with tokio by using an async DNS resolution solution, which is what Go is doing in their stdlib for you.

by fooyc 10y ago

Seriously, with async you can just trash all your code because it will block your async event loop. So you have to rewrite every single library and network client in asynchronous mode.

akiselev 10y ago

You don't have to rewrite the (vast) majority of crates to be asynchronous because almost all of them can run from a thread pool with zero problems. Worst case scenario, you spawn a new OS thread and return a future which integrates very well with Tokio. Since it's built on top of futures-rs it will play nicely with other asynchronous crates and wrapping a synchronous library is much easier than rewriting it. It would be great to have every I/O library use OS specific polling mechanisms but that places a significant burden on library developers to not only know their domain, but have experience with each platforms quirks and limitations.

fooyc 10y ago
> all of them can run from a thread pool with zero problems Until you exhaust the thread pool, in which case everything relying on the thread pool will be much longer than usual to complete. Nodejs does this for name resolving, and it's a nightmare. Basically, with the default pool of 4 threads, it suffices of 4 slow resolves to DoS everything that needs to do a name resolve in the same process. I hope that Rust will not have the same problem when mixing async and thread pools. If the thread pool is not limited in size, you avoid this problem, but you lose all the benefits of async.
- amaranth 10y ago
  > If the thread pool is not limited in size, you avoid this problem, but you lose all the benefits of async. You can't have both: either you have a limited pool and can block it on long running tasks or you don't and can wind up with a large number of threads. Go currently doesn't give you this choice and you're limited by whatever you set GOMAXPROCS to before you start your program. If you have GOMAXPROCS set to 4 and you have 4 goroutines that take a long time (not waiting for IO) you've blocked the ability to do any other work. This isn't entirely true of course because they have a runtime in-process scheduler (which adds more overhead) but you could easily avoid this particular problem with tokio by using an async DNS resolution solution, which is what Go is doing in their stdlib for you.