[swift-evolution] Question about async await

[Adam Kemp]

> On Sep 25, 2017, at 9:54 AM, Trevör Anne Denise via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Did anyone started to sketch a design for how giving back control to the calling queue will work ?
> 

This thread had some ideas:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039349.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039349.html>

C# uses the SynchronizationContext class <https://msdn.microsoft.com/en-us/library/system.threading.synchronizationcontext(v=vs.110).aspx <https://msdn.microsoft.com/en-us/library/system.threading.synchronizationcontext(v=vs.110).aspx>>. 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.

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.

I could imagine a concept like SynchronizationContext in Swift which captures the current queue and then can post work back to that same queue.

> 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 ?
> 
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170925/49749322/attachment.html>