[swift-evolution] [Concurrency] A slightly different perspective

[David Hart]

> On 2 Sep 2017, at 20:24, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Aug 31, 2017, at 3:04 PM, Nathan Gray via swift-evolution <swift-evolution at swift.org> wrote:
>> I've been following the conversations around Chris Lattner's intriguing async/await proposal and would like to offer my own take. I feel that the proposal as written is almost perfect.  My suggestions for improving it are not highly original -- I think they have all come up already -- but I'd like to present them from my own perspective.
>> 
>> 1. Fixing "queue confusion" *must* be part of this proposal.  The key bit of "magic" offered by async/await over continuation passing is that you're working in a single scope.  A single scope should execute on a single queue unless the programmer explicitly requests otherwise.  Queue hopping is a surprising problem in a single scope, and one that there's currently no adequate solution for.
> 
> As mentioned downthread, the “contextualizing” thread is one way to address this.
> 
>> 2. The proposal should include some basic coordination mechanism.  The argument against returning a Future every time `await` is called is convincing, so my suggestion is to do it from `beginAsync`. The Future returned should only be specified by protocol. The protocol can start with minimal features -- perhaps just cancellation and progress.  There should be a way for programmers to specify their own, more featureful, types. (The proposal mentions the idea of returning a Bool, which is perhaps the least-featureful Future type imaginable. :-)
> 
> Please don’t read too much into the beginAsync API.  It is merely a strawman, and intended to be a low-level API that higher level abstractions (like a decent futures API) can be built on top of.  I think it is important to have some sort of primitive low-level API that is independent of higher level abstractions like Futures.
> 
> This is all a way of saying “yes, having something like you propose makes sense” but that it should be part of the Futures API, which is outside the scope of the async/await proposal.

But it would be nice for all high-level APIs that conform to a Awaitable protocol to be used with await without having to reach for a get property or something similar everytime.

> -Chris
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170903/32afbda1/attachment.html>