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

Thomas tclementdev at free.fr
Thu Aug 24 17:15:39 CDT 2017


> On 24 Aug 2017, at 23:47, Adam Kemp <adam.kemp at apple.com> wrote:
> 
> 
>> On Aug 24, 2017, at 1:05 PM, Thomas via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On 24 Aug 2017, at 21:48, Marc Schlichte <marc.schlichte at googlemail.com <mailto:marc.schlichte at googlemail.com>> wrote:
>>> 
>>> Yes, I think it is mandatory that we continue on the callers queue after an `await ` on some actor method.
>>> 
>>> If you `await` on a non-actor-method though, you would have to changes queues manually if needed.
>>> 
>>> Any `actor` should have a `let actorQueue: DispatchQueue` property so that we can call in these cases:
>>> 
>>> ```await actorQueue.asyncCoroutine()``` as mentioned in the manifesto.
>> 
>> Wouldn't that be really confusing though? That awaiting certain methods would bring us back to the actor's queue but awaiting others would require manual queue hopping? What if the compiler was to always generate the 'await actorQueue.asyncCoroutine()' queue hopping code after awaiting on an async/actor method?
> 
> Yes, it would be confusing. await should either always return to the same queue or never do it. Otherwise it’s even more error-prone. I see the actor feature as being just another demonstration of why solving the queue-hopping problem is important for async/await to be useful.

So the way a non "fire and forget" actor method would work is:

- the actor's queue is in a suspended state until the method returns, this is required so that messages sent to other actor methods are not processed (they're added to the queue)
- if the method body awaits on some other code, it automatically jumps back on the actor's queue after awaiting, regardless of the queue's suspension and content
- when the method returns, the actor's queue is resumed and pending messages can be processed (if any)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170825/8aad5f80/attachment.html>


More information about the swift-evolution mailing list