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

[Thomas]

> On 18 Aug 2017, at 21:11, Joe Groff <jgroff at apple.com> wrote:
> 
> 
>> On Aug 18, 2017, at 11:57 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I think that awaiting on the result of an actor method ends up being pretty similar (in terms of implementation and design tradeoffs) as dispatch_sync.  That said, my understanding is that thread explosion in GCD happens whenever something blocks a GCD thread, not when it politely yields control back to GCD.  Am I misunderstanding what you mean.
> 
> dispatch_sync isn't quite the ideal way of thinking about it, since it will block the calling context, and as you note this would potentially deadlock the current thread if an actor invokes one of its own methods. This isn't a desirable or fundamentally necessary pitfall, since really, the caller actor is suspending in wait simultaneously with the callee actor taking control. This is more like a "tail-dispatch_async" kind of operation, where you don't really want the calling context to block, but you still want to be able to reuse the current thread since it'll be immediately freed up by blocking on the async operation. That's something we could conceivably build into runtime support for this model.

You seem to imply we are able to jump on the callee actor queue immediately, but the queue may not be available (the actor could be processing another message). So I'm not sure how it goes in term of reusing the same thread, maybe there's some clever trick to do this if it can be determined that the queue is immediately available. But using dispatch_sync() wouldn't work for me as it would potentially block the caller GCD thread and that could end up with thread explosion.

Thomas