Thank you ! That's exactly what I was looking for ! Trevör
> Le 25 sept. 2017 à 19:32, Adam Kemp <adam_k...@apple.com> a écrit : > > > >> On Sep 25, 2017, at 9:54 AM, Trevör Anne Denise via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
