> On Aug 18, 2017, at 3:11 PM, Joe Groff via swift-evolution > <[email protected]> wrote: > >> 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.
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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
