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

[Thorsten Seitz]

> Am 20.08.2017 um 04:38 schrieb Thomas via swift-evolution <swift-evolution at swift.org>:
> 
> 
>>> On 20 Aug 2017, at 03:36, Brent Royal-Gordon <brent at architechies.com> wrote:
>>> 
>>>> On Aug 19, 2017, at 2:25 AM, Thomas <tclementdev at free.fr> wrote:
>>>> 
>>>> I think we need to be a little careful here—the mere fact that a message returns `Void` doesn't mean the caller shouldn't wait until it's done to continue. For instance:
>>>> 
>>>> 	listActor.delete(at: index)				// Void, so it doesn't wait
>>>> 	let count = await listActor.getCount()	// But we want the count *after* the deletion!
>>> 
>>> In fact this will just work. Because both messages happen on the actor's internal serial queue, the "get count" message will only happen after the deletion. Therefore the "delete" message can return immediately to the caller (you just need the dispatch call on the queue to be made).
>> 
>> Suppose `delete(at:)` needs to do something asynchronous, like ask a server to do the deletion. Is processing of other messages to the actor suspended until it finishes? (Maybe the answer is "yes"—I don't have experience with proper actors.)
> 
> It seems like the answer should be "yes". But then how do you implement something like a cancel() method? I don't know how the actor model solves that problem.

Processing of other messages to the actor should be suspended until `delete(at:)` finishes. Otherwise the actor's state would not be protected properly. But obviously this does not help if `delete(at:)` itself delegates the deletion to another actor with a fire-and-forget message.

-Thorsten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170911/06a25fbd/attachment.html>