> On 24 Aug 2017, at 23:47, Adam Kemp <[email protected]> wrote: > > >> On Aug 24, 2017, at 1:05 PM, Thomas via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>> On 24 Aug 2017, at 21:48, Marc Schlichte <[email protected] >>> <mailto:[email protected]>> 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)
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
