owned this note changed 2 years ago
Published Linked with GitHub

Deep dive notes: futures-concurrency

Links to documents:

tags: deep-dive

Leave questions, observations, discussion topics below.


Topic

name: prompt


eholk: Does it make more sense to most futures-concurrency under rust-lang, or just piece-wise migrate all of it into std and skip the rust-lang step?

yosh: We could do that, valid option. Skip it if it's controversial.

Might be useful because e.g. AsyncIterator is not ready to stabilize. But people are using async now, with Stream.


tmandry: Anyone using it?

yosh: Microsoft, phil-opp, a few.


tmandry: What have you not included?

yosh: Focused on bounded concurrency: tuples, arrays. Lots of work to be done on dynamic concurrency.

Might be in scope, but want to narrow it down. The join RFC will be further narrowed down to just that.


(continued from above question)

yosh: Parallelism. tasky investigates this more.

  • Stops thinking of a task an async version of a thread, but as a parallelizable version of a Future.
  • Doesn't start until you await it.
  • This gives you a handle that propagates errors and cancellation.

tmandry: Also adopted a Task handle API by default on fuchsia executor, with a .detach() escape hatch.

eholk: Unix processes work the same way.

yosh: What about zombie processes?

yosh: I suspect we can use new patterns to avoid needing .detach()


tmandry: Why not .join()? :)

yosh: []::join already exists -_-.

Just use IntoFuture?

eholk: .await_all?

yosh: Swift's async let is really interesting. You can be binding multiple things at once.

async let a = b()
async let c = d()
// b, d can run concurrently at this point

Infers the await graph for you!


Select a repo