> On Aug 18, 2017, at 12:23 PM, Thomas <tclement...@free.fr> wrote: > > >> On 18 Aug 2017, at 20:57, Chris Lattner <clatt...@nondot.org> wrote: >> >>> 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. >> >> 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. > > disptach_sync() calls will cause the GCD thread to block (waiting for the > queue to be available). I'm pretty sure this causes libdispatch to spawn more > threads if needed (for example if dispatch_async() calls are made in other > parts of the program), up to thread explosion.
Ok, my misunderstanding. That does make it a bad analogy, I’ll update the proposal. -Chris _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
