> On Sep 4, 2017, at 9:05 AM, Jean-Daniel <[email protected]> wrote: > >>> Sometimes, I’d probably make sense (or even be required to fix this to a >>> certain queue (in the thread(-pool?) sense), but at others it may just make >>> sense to execute the messages in-place by the sender if they don’t block so >>> no context switch is incurred. >> >> Do you mean kernel context switch? With well behaved actors, the runtime >> should be able to run work items from many different queues on the same >> kernel thread. The “queue switch cost” is designed to be very very low. >> The key thing is that the runtime needs to know when work on a queue gets >> blocked so the kernel thread can move on to servicing some other queues work. > > My understanding is that a kernel thread can’t move on servicing a different > queue while a block is executing on it. The runtime already know when a queue > is blocked, and the only way it has to mitigate the problem is to spawn an > other kernel thread to server the other queues. This is what cause the kernel > thread explosion.
I’m not sure what you mean by “executing on it”. A work item that currently has a kernel thread can be doing one of two things: “executing work” (like number crunching) or “being blocked in the kernel on something that GCD doesn’t know about”. However, the whole point is that work items shouldn’t do this: as you say it causes thread explosions. It is better for them to yield control back to GCD, which allows GCD to use the kernel thread for other queues, even though the original *queue* is blocked. -Chris
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
