<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="">On 25 Aug 2017, at 10:14, 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 25 Aug 2017, at 01:15, Adam Kemp <<a href="mailto:adam.kemp@apple.com" class="">adam.kemp@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div 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;" class=""><br class="Apple-interchange-newline"><br class=""><blockquote type="cite" class=""><div class="">On Aug 24, 2017, at 3:15 PM, Thomas <<a href="mailto:tclementdev@free.fr" class="">tclementdev@free.fr</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="">On 24 Aug 2017, at 23:47, Adam Kemp <<a href="mailto:adam.kemp@apple.com" class="">adam.kemp@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 24, 2017, at 1:05 PM, 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=""><div class="" style="font-family: Helvetica; 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=""><div class=""><br class="Apple-interchange-newline">On 24 Aug 2017, at 21:48, Marc Schlichte <<a href="mailto:marc.schlichte@googlemail.com" class="">marc.schlichte@googlemail.com</a>> wrote:</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><div class=""><div class=""><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 class=""><br class=""></div><div class="">If you `await` on a non-actor-method though, you would have to changes queues manually if needed.</div><div class=""><br class=""></div><div class="">Any `actor` should have a `let actorQueue: DispatchQueue` property so that we can call in these cases:</div><div class=""><br class=""></div><div class="">```await actorQueue.asyncCoroutine()``` as mentioned in the manifesto.</div></div></div></blockquote><br class=""></div><div class="" style="font-family: Helvetica; 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;">Wouldn't that be really confusing though? That awaiting certain methods would bring us back to the actor's queue but awaiting others would require manual queue hopping? What if the compiler was to always generate the 'await actorQueue.asyncCoroutine()' queue hopping code after awaiting on an async/actor method?</div></div></blockquote></div><br class=""><div class="">Yes, it would be confusing. await should either always return to the same queue or never do it. Otherwise it’s even more error-prone. I see the actor feature as being just another demonstration of why solving the queue-hopping problem is important for async/await to be useful.</div></div></div></blockquote></div><br class=""><div class="">So the way a non "fire and forget" actor method would work is:</div><div class=""><br class=""></div><div class="">- the actor's queue is in a suspended state until the method returns, this is required so that messages sent to other actor methods are not processed (they're added to the queue)</div><div class="">- if the method body awaits on some other code, it automatically jumps back on the actor's queue after awaiting, regardless of the queue's suspension and content</div><div class="">- when the method returns, the actor's queue is resumed and pending messages can be processed (if any)</div><div class=""><br class=""></div></div></div></blockquote></div><br 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;"><div 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;">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: 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;"><br class=""></div><div 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;">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="">It is correct that suspending the queue allows for deadlocks, but not doing it means you can receive messages while still in the middle of another message. For the same reason you may need FIFO ordering in a class to guarantee coherency, you will want this to work in an asynchronous world as well. Take for example some storage class:</div><div class=""><br class=""></div><div class="">1. store(object, key)</div><div class="">2. fetch(key)</div><div class=""><br class=""></div><div class="">If you're doing these operations in order, you want the fetch to return the object you just stored. If the 'store' needs to await something in its implementation and we were to not suspend the queue, the fetch would be processed before the object is actually stored and it would return something unexpected.</div></div></div></blockquote><br class=""></div><div>Also think about this storage class being used concurrently. If the 'store' method is called concurrently and you don't suspend the queue, you'd end up with some of these 'store' requests processed while possibly in the middle of previous 'store' requests. That doesn't seem very safe. Soon enough, you'll end up wanting to wrap your class into an async FIFO pipeline.</div><br class=""><div class="">Thomas</div><div class=""><br class=""></div></body></html>