<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 25.08.2017 um 01:15 schrieb Adam Kemp 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="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;">I don’t think await should cause the actor’s queue (or any queue) to be suspended. Actor methods should not block waiting for asynchronous things. That’s how you get deadlocks. If an actor method needs to be async then it should work just like any async method on the main queue: it unblocks the queue and allows other messages to be processed until it gets an answer.</div><div 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;"><br class=""></div><div 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;">You do have to be aware of the fact that things can happen in between an await and the next line of code, but conveniently these places are all marked for you. They all say “await”. :)</div></div></blockquote></div><br class=""><div class="">Yes, that is important to note: when we `await` on an `async` method, the callers queue does not get blocked in any way. The control flow just continues - with the next instruction after the enclosing `beginAsync` I suppose - and when done with the current DispatchWorkItem just dequeues the next DispatchWorkItem and works on it. If there is no next item, the underlying thread might still not be suspend but be used to work on some another queue.</div><div class=""><br class=""></div><div class="">Despite that, we might still want to discuss if actor-methods should get serialized beyond that - think of an underlying GCD queue (as discussed above) and a separate (non-GDC) message-queue where actor messages will get queued up. In another thread I proposed to introduce a new modifier for actor methods which will not put them into the message-queue and which are thus allowed to run whenever the GCD queue picks them up:</div><div class=""><br class=""></div><div class="">serialized by message-queue: </div><div class="">`actor func foo() async`</div><div class=""><br class=""></div><div class="">non-serialized:</div><div class="">`interleaved actor func bar() async`</div><div class=""><br class=""></div><div class="">This way, when you reason about your code and look at places marked with `await`, only `interleaved` methods (or code using explicit `beginAsync` calls) might have changed your state.</div><div class=""><br class=""></div><div class="">Cheers</div><div class="">Marc</div><div class=""><br class=""></div></body></html>