> On Aug 18, 2017, at 11:57 AM, Chris Lattner via swift-evolution 
> <[email protected]> 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.

-Joe
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to