On the proliferation of try (and, soon, await)

[dabrahams (Dave Abrahams)]

@adamkemp

@dabrahams

Are you saying that await signals code that would otherwise (in a non- async world) block, and thus provide an opportunity for the current thread to do other useful work?

await signals that you are potentially giving up your thread (and thus giving up the CPU) while waiting for some asynchronous response. Most likely the response you're waiting for won't be consuming any CPU itself while you're waiting so you are giving up control over the CPU to do nothing in the meantime. So the placement of that await relative to other code that you need to run is important information. Placing that await in the right place can make a significant difference in throughput. If the waiting were done implicitly then you wouldn't know to move it.

@dabrahams

IIUC, you're saying await serves as an important clue that async let can be used to improve performance

Yes!

@dabrahams

My point is that, if async let will dispatch to another thread when necessary/appropriate, then it could be used to improve performance even if the code were sync

That is not what async let is proposed to do. async let does not introduce concurrency.

OK, I'm really sorry to do this because I am sure you have a lot more experience with async than I do, but it sounds like you are mixing up concurrency and parallelism. My understanding is that the one thing async let is guaranteed to do is introduce concurrency. It was also my understanding that whether it introduces parallelism may depend on the current executor, although available information about the role of executors has been somewhat thin.

Also, according to [Concurrency] Structured concurrency,

@John_McCall

we can break down our recipe into different tasks that can happen in parallel.

Maybe that was just casual speaking but I guess that may have led me to believe things could happen in parallel. If that's not the case, it would seem to indicate these proposals aren't offering a replacement for DispatchQueue.concurrentPerform, which is an interesting twist to how I've been reading things.

Note that I'm not the only one who has suggested async will be used for parallelism, and nobody has corrected them so far:

[Concurrency] async/await + actors

Because async/await serve a different (but related) purpose than background threads. Remember that concurrency is not parallelism: running in parallel in the background is a useful construction, but not the *only* construction. If you have multiple tasks you’d like to kick off in parallel, async/await can support that by providing some kind of awaitable Future object. You’d then call multiple functions that return those futures and then await on the completion of all of the Futures (Future.gath…

[Concurrency] async/await + actors

Would it be possible to implement just the concurrency part without parallelism and GCD? That is, async functions called with await would always execute on the same thread they were called? My understanding is that this would be quite similar (if not the same conceptually) as generators/yield, is that correct?

@John_McCall, @Douglas_Gregor care to comment? Is parallelism in or out of scope for async/await?