[swift-evolution] [Concurrency] async/await + actors

[Adam Kemp]

> On Sep 11, 2017, at 1:15 PM, Kenny Leung via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I found a decent description about async/await here:
> 
> https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/ <https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/>
> 
> So it’s much more like runloop based callbacks in Foundation that libdispatch. It’s complicated. Even the simplest example is super complicated. 
> 
> It’s super implicit (like, “I’m going to package up every line of code from await to the end of this function and turn it into a continuation”). That seems to go against one of the primary principles of Swift, which is to make things plain to the reader. I’d be interested to know what the call stack looks like on the line after await.

This is pretty much how it would have to work for Swift as well. The call stack after the await (in C#) would either start at the runloop and go through the futures API (usually Task) or it would start at whatever code satisfied the async request.

It’s true that this can make it more difficult to understand stack traces. In most cases the original call stack is lost. Microsoft has made changes to Visual Studio in order to show kind of an alternative stack trace for tasks to try to make this better. I think they also made things like F10 (step over) and F11 (step out) do the natural thing (i.e., wait for the continuation).

> 
> The doc takes away some of the mystery, but leaves major questions, like: await is used to yield control to the parent, but at the bottom of the call stack, presumably you’re going to do something blocking, so how do you call await?

One of the common misconceptions about async/await (which I also had when I first encountered it) is that there must be a blocking thread somewhere. It doesn’t work that way. The “bottom of the call stack” is typically either a run loop or a thread pool with a work queue (really just another kind of run loop). I guess you’re right in the sense that those kinds of run loops do block, but they’re not blocking on any particular piece of work to be done. They’re blocking waiting for ANY more work to be done (either events or items placed in the work queue).

The way that the continuation works is that it is placed onto one of those queues. For the UI thread it’s kind of like doing performSelectorOnMainThread: (the .Net equivalent is usually called BeginInvokeOnMainThread). For a thread pool there’s another API. For GCD this would be like doing a dispatch_async. It’s putting the continuation callback block onto a queue, and that callback will be called when the run loop or the thread pool is able to do so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170911/e64b3007/attachment.html>