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

[John McCall]

> On Aug 18, 2017, at 3:11 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> 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.

As well as more perniciously creating deadlock opportunities if there are cycles in actors dispatching to each other.  It really has to be a "re-queue when there's a response" model.

John.

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