[quote='816385022, DTS Engineer, /thread/770062?answerId=816385022#816385022'] That’s about it. [/quote] I have to admit that I’m mildly disappointed! I’d kind of convinced myself that workloops must be some sort of dark magic. [quote='816385022, DTS Engineer, /thread/770062?answerId=816385022#816385022'] Because the workloop is intended to be the target, not the source, of work. The idea is to have one workloop per subsystem and then have various serial queue, or serial queue hierarchies, target that. [/quote] This makes sense, thank you! I can see how workloops map well onto the ideas presented in the WWDC session you linked. Keep using serial queues where ordering matters, otherwise target everything at one workloop (instead of a serial queue) per subsystem. [quote='816385022, DTS Engineer, /thread/770062?answerId=816385022#816385022'] Honestly, if you could set a target queue I’m not sure how that’d even work. If you set a workloop’s target queue to a serial queue, you’d be back in FIFO Land™. [/quote] I was imagining that targeting a workloop at a serial queue would interleave the workloop’s work items (which are still ordered by priority) with the serial queue’s other work items (which maintain their ordering); it’s as if you’d targeted one serial queue at another, except that the first queue happens to have had its work submitted in descending priority order. Targeting a workloop at another workloop would function in the same way as how targeting a serial queue at a workloop does today, minus the ordering requirement. I suppose the purpose of this would be the same as why we target serial queues at one another: to apply labels for debugging and to assign QoS classes. Of course, none of this matters since I’m just imagining things. [quote='816385022, DTS Engineer, /thread/770062?answerId=816385022#816385022'] ps I love your blog! [/quote] Thank you for the compliment and for the fantastic answers!

I’ve filed it FB14027711.