|
@withoutboats | |||||
|
This is really cool!! Some thoughts follow twitter.com/asyncrs/status…
|
||||||
|
||||||
|
Saoirse Shipwreckt
@withoutboats
|
17. pro |
|
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
|
||
|
|
||
|
Saoirse Shipwreckt
@withoutboats
|
17. pro |
|
This is probably well suited to many applications, especially many classes of network services - again, exactly where Go thrives
|
||
|
|
||
|
Saoirse Shipwreckt
@withoutboats
|
17. pro |
|
But there are other targets (eg soft real time systems) where this would be very inappropriate. They should use a different runtime
|
||
|
|
||
|
Saoirse Shipwreckt
@withoutboats
|
17. pro |
|
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
|
||
|
|
||
|
Saoirse Shipwreckt
@withoutboats
|
17. pro |
|
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
|
||
|
|
||
|
Kevin Wang
@wy721
|
17. pro |
|
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.
|
||
|
|
||
|
James Munns
@bitshiftmask
|
17. pro |
|
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.
|
||
|
|
||