> Am 24.08.2017 um 01:56 schrieb Adam Kemp <[email protected]>: > > > >> On Aug 23, 2017, at 4:28 PM, Marc Schlichte via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >>> Am 23.08.2017 um 12:29 schrieb Thomas via swift-evolution >>> <[email protected] <mailto:[email protected]>>: >>> >>> >>>> On 23 Aug 2017, at 11:28, Thomas via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> 1. What happens to the actor's queue when the body of a (non >>>> void-returning) actor method awaits away on some other actor? Does it >>>> suspend the queue to prevent other messages from being processes? It would >>>> seem to be the expected behavior but we'd also need a way to detach from >>>> the actor's queue in order to allow patterns like starting a long-running >>>> background operation and still allowing other messages to be processed >>>> (for example, calling a cancel() method). We could still do these >>>> long-running operations by passing a completion block to the method, >>>> rather than via its return value. That would clarify this goes beyond this >>>> one actor message, but we're back to the old syntax... >>> >>> Maybe that's where Futures would come in handy? Just return a Future from >>> the method so callers can await long-running operations. >> >> If you wrap the call to a long-running operation of another actor in a >> `beginAsync`, I would assume that other `actor funcs` of your actor will be >> able to run even while >> the long-running operation is pending: >> >> actor class Caller { >> let callee = Callee() >> var state = SomeState() >> >> actor func foo() { >> beginAsync { >> let result = await callee.longRunningOperation() >> // do something with result and maybe state >> } >> } >> actor func bar() { >> // modify actor state >> } >> } > > As currently proposed, the “// do something with result and maybe state” line > would likely run on Callee’s queue, not Caller’s queue. I still strongly > believe that this behavior should be reconsidered. > > It does, however, bring up some interesting questions about how actors > interact with themselves. One of the rules laid out in Chris’s document says > that “local state and non-actor methods may only be accessed by methods > defined lexically on the actor or in an extension to it (whether they are > marked actor or otherwise).” That means it would be allowed for the code in > foo() to access state and call non-actor methods, even after the await. As > proposed that would be unsafe, and since the queue is an implementation > detail inaccessible to your code there wouldn’t be a straightforward way to > get back on the right queue to make it safe. I presume you could call another > actor method to get back on the right queue, but having to do that explicitly > after every await in an actor method seems tedious and error prone. > > In order to have strong safety guarantees for actors you would want to ensure > that all the code that has access to the state runs on the actor’s queue. > There are currently two holes I can think of that would prevent us from > having that protection: await and escaping blocks. await could be made safe > if it were changed to return to the calling queue. Maybe escaping blocks > could be restricted to only calling actor methods.
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. Cheers Marc > >> >> Note, that in this case while waiting asynchronously on the long-running >> operation, the state of the caller might get changed by another of its >> `actor funcs` running. >> Sometimes this might be intended - e.g. for cancellation - but it also could >> lead to hard to find bugs... >> >>> >>> Thomas >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
