[swift-evolution] [Concurrency] async/await + actors

[Alejandro Martinez]

This has been a long awaited topic so I'm really excited to see the
conversation start!
After reading the manifesto and the proposal there is one thing that
keeps wondering in my head, and is making async implicitly throwing.
It the common case it makes sense, but there is a part of the proposal
that talks about "yields" and how the implementation is "coroutines"
that can be used for other things not only for concurrent operations.
In that case, wouldn't make more sense to keep throwing separated?

On Fri, Aug 18, 2017 at 2:17 PM, Thomas via swift-evolution
<swift-evolution at swift.org> wrote:
> I have been writing a lot of fully async code over the recent years (in objc) and this all seems to fit well with what we're doing and looks like it would alleviate a lot of the pain we have writing asyc code.
>
> # Extending the model through await
>
> I'm a bit worried about the mention of dispatch_sync() here (although it may just be there to illustrate the deadlock possibility). I know the actor runtime implementation is not yet defined, but just wanted to mention that dispatch_sync() will lead to problems such as this annoying thing called thread explosion. This is why we currently cannot use properties in our code (getters would require us to call dispatch_sync() and we want to avoid that), instead we are writing custom async getters/setters with callback blocks. Having async property getters would be pretty awesome.
>
> Another thing: it is not clearly mentionned here that we're getting back on the caller actor's queue after awaiting on another actor's async method.
>
> # Scalable Runtime
>
> About the problem of creating too many queues. This is something that has annoyed me at this year's wwdc. It used to be back when the libdispatch was introduced in 10.6 that we were told that queues are very cheap, we could create thousands of them and not worry about threads, because the libdispatch would do the right thing internally and adjust to the available hardware (the number of threads would more or less match the number of cores in your machine). Somehow this has changed, now we're being told we need to worry about the threads behind the queues and not have too many of them. I'm not sure if this is something inevitable due to the underlying reality of the system but the way things were presented back then (think in term of queues, don't worry about threads) was very compelling.
>
> # Entering and leaving async code
>
> Certainly seems like the beginAsync(), suspendAsync() primitives would be useful outside of the stdlib. The Future<T> example makes use of suspendAsync() to store the continuation block and call it later, other codes would do just as well.
>
> Shouldn't this:
>
>> let imageTmp    = await decodeImage(dataResource.get(), imageResource.get())
>
> rather be:
>
>> let imageTmp    = await decodeImage(await dataResource.get(), await imageResource.get())
>
>
> Thomas
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



-- 
Alejandro Martinez
http://alejandromp.com