Twitter | Pretraživanje | |
Saoirse Shipwreckt 17. pro
Odgovor korisniku/ci @withoutboats
The comparison to go is very apt: async-std’s design (including this feature) pushes more and more toward using tasks as the unit of concurrency. This is just like goroutines
Reply Retweet Označi sa "sviđa mi se"
Saoirse Shipwreckt 17. pro
Odgovor korisniku/ci @withoutboats
This is probably well suited to many applications, especially many classes of network services - again, exactly where Go thrives
Reply Retweet Označi sa "sviđa mi se"
Saoirse Shipwreckt 17. pro
Odgovor korisniku/ci @withoutboats
But there are other targets (eg soft real time systems) where this would be very inappropriate. They should use a different runtime
Reply Retweet Označi sa "sviđa mi se"
Saoirse Shipwreckt 17. pro
Odgovor korisniku/ci @withoutboats
This is why the separation of concerns between executor, reactor, and middleware is so important: we *should* have many different runtimes optimized for different use cases
Reply Retweet Označi sa "sviđa mi se"
Saoirse Shipwreckt 17. pro
Odgovor korisniku/ci @withoutboats
One library cannot be the runtime for every use case. Runtime authors should try to pick a particular target user, and other libraries should be written to be abstract over different runtimes
Reply Retweet Označi sa "sviđa mi se"
Kevin Wang 17. pro
Odgovor korisniku/ci @withoutboats
This encourages blocking within async fn without worry. The consequense is: Now, I can not write code like this: let a = async_fn_from_a_crate(); let b = another_async_fn(); join!(a, b).await; I am not sure whether the a and b would block each other.
Reply Retweet Označi sa "sviđa mi se"
James Munns 17. pro
Odgovor korisniku/ci @wy721 @withoutboats
Isn't this true already if one took a long time, even nonblocking? If your first async function took 10s to download a file (totally async), it would still "block" your second one. This just keeps the first async function from starving the executor of time.
Reply Retweet Označi sa "sviđa mi se"