<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 24.08.2017 um 01:56 schrieb Adam Kemp <<a href="mailto:adam.kemp@apple.com" class="">adam.kemp@apple.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class="">On Aug 23, 2017, at 4:28 PM, Marc Schlichte via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">Am 23.08.2017 um 12:29 schrieb Thomas via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 23 Aug 2017, at 11:28, Thomas via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span class="" style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">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...</span></div></blockquote></div><br class=""><div class="">Maybe that's where Futures would come in handy? Just return a Future from the method so callers can await long-running operations.</div></div></div></blockquote><div class=""><br class=""></div><div class="">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</div><div class=""> the long-running operation is pending:</div><div class=""><br class=""></div><div class="">actor class Caller {</div><div class=""> let callee = Callee()</div><div class=""> var state = SomeState()</div><div class=""><br class=""></div><div class=""> actor func foo() {</div><div class=""> beginAsync {</div><div class=""> let result = await callee.longRunningOperation()</div><div class=""> // do something with result and maybe state</div><div class=""> }</div><div class=""> }</div><div class=""> actor func bar() {</div><div class=""> // modify actor state</div><div class=""> }</div><div class="">}</div></div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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.</div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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.</div></div></blockquote><div><br class=""></div>Yes, I think it is mandatory that we continue on the callers queue after an `await ` on some actor method.</div><div><br class=""></div><div>If you `await` on a non-actor-method though, you would have to changes queues manually if needed.</div><div><br class=""></div><div>Any `actor` should have a `let actorQueue: DispatchQueue` property so that we can call in these cases:</div><div><br class=""></div><div>```await actorQueue.asyncCoroutine()``` as mentioned in the manifesto.</div><div><br class=""></div><div>Cheers</div><div>Marc</div><div><blockquote type="cite" class=""><div class=""><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><br class=""></div><div class="">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.</div><div class="">Sometimes this might be intended - e.g. for cancellation - but it also could lead to hard to find bugs...</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">Thomas</div><div class=""><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></blockquote></div><br class=""></body></html>