> 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
