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

Thomas tclementdev at free.fr
Fri Aug 18 08:17:05 CDT 2017

I have been writing a lot of fully async code over the recent years (in objc) and this all seems to fit well with what we're doing and looks like it would alleviate a lot of the pain we have writing asyc code.

# Extending the model through await

I'm a bit worried about the mention of dispatch_sync() here (although it may just be there to illustrate the deadlock possibility). I know the actor runtime implementation is not yet defined, but just wanted to mention that dispatch_sync() will lead to problems such as this annoying thing called thread explosion. This is why we currently cannot use properties in our code (getters would require us to call dispatch_sync() and we want to avoid that), instead we are writing custom async getters/setters with callback blocks. Having async property getters would be pretty awesome.

Another thing: it is not clearly mentionned here that we're getting back on the caller actor's queue after awaiting on another actor's async method.

# Scalable Runtime

About the problem of creating too many queues. This is something that has annoyed me at this year's wwdc. It used to be back when the libdispatch was introduced in 10.6 that we were told that queues are very cheap, we could create thousands of them and not worry about threads, because the libdispatch would do the right thing internally and adjust to the available hardware (the number of threads would more or less match the number of cores in your machine). Somehow this has changed, now we're being told we need to worry about the threads behind the queues and not have too many of them. I'm not sure if this is something inevitable due to the underlying reality of the system but the way things were presented back then (think in term of queues, don't worry about threads) was very compelling.

# Entering and leaving async code

Certainly seems like the beginAsync(), suspendAsync() primitives would be useful outside of the stdlib. The Future<T> example makes use of suspendAsync() to store the continuation block and call it later, other codes would do just as well.

Shouldn't this:

> let imageTmp    = await decodeImage(dataResource.get(), imageResource.get())

rather be:

> let imageTmp    = await decodeImage(await dataResource.get(), await imageResource.get())


More information about the swift-evolution mailing list