<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thank you ! That's exactly what I was looking for !<div class=""><br class=""></div><div class="">Trevör<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Le 25 sept. 2017 à 19:32, Adam Kemp <<a href="mailto:adam_kemp@apple.com" class="">adam_kemp@apple.com</a>> a écrit :</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; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 25, 2017, at 9:54 AM, Trevör Anne Denise via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Did anyone started to sketch a design for how giving back control to the calling queue will work ?</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">This thread had some ideas:</div><div class=""><br class=""></div><div class=""><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039349.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039349.html</a></div><div class=""><br class=""></div><div class="">C# uses the SynchronizationContext class <<a href="https://msdn.microsoft.com/en-us/library/system.threading.synchronizationcontext(v=vs.110).aspx" class="">https://msdn.microsoft.com/en-us/library/system.threading.synchronizationcontext(v=vs.110).aspx</a>>. This class abstracts the concept of performing work synchronously or asynchronously using different threading models. For instance, there’s an implementation that posts messages to the UI thread and another that posts them to a thread pool. Each thread has a current context, which can be set with a static method.</div><div class=""><br class=""></div><div class="">The C# async/await feature itself doesn’t know anything about this, but its futures implementation (System.Threading.Tasks.Task) can be configured to run its continuation on the SynchronizationContext that was current when the task was started. If you use Task with async/await then it will “Just Work”. If you use some other futures implementation with async/await then it’s up to that implementation to decide what to do with the continuations.</div><div class=""><br class=""></div><div class="">I could imagine a concept like SynchronizationContext in Swift which captures the current queue and then can post work back to that same queue.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Would it make any sense to limit asyncCorountine() to the scope of the function where it gets called and implicitly "hop back" to the calling queue so that no shared mutable state issues arise ?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></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></div></blockquote></div><br class=""></div></body></html>