> Am 20.08.2017 um 04:38 schrieb Thomas via swift-evolution 
> <swift-evolution@swift.org>:
> 
> 
>>> On 20 Aug 2017, at 03:36, Brent Royal-Gordon <br...@architechies.com> wrote:
>>> 
>>>> On Aug 19, 2017, at 2:25 AM, Thomas <tclement...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to