I think using priorities is a Bad Idea™, as explained [here](http://www.objc.io/issue-2/concurrency-apis-and-pitfalls.html#priority_inversion). Go read that, I'll wait ;-). Back ? Good, now read the rest of the article, it's very well done :-D.

Joking aside, I don't think having separate "priority" helpers is a good idea (as the article suggests). I'm pretty sure I've seen QS act like that because the main thread is now considered a "resource" because it's the only one that can do UI directly, and thus, firing 200 icon loads (even on a background queue) that will end up updating objects on the main thread *synchronously* will end badly (as #1607, #1603 seems to imply). An implicit rule I can think of is *never* `dispatch_sync` on the main thread things that 1) don't explicitly care about what's returned and 2) — and this is major — `dispatch_sync` again somewhere else (example [here](https://github.com/quicksilver/Quicksilver/blob/538d3cbea3f0b73e1aba7eddf5479e0fd9d036e0/Quicksilver/Code-QuickStepInterface/QSResultController.m#L312)) though it doesn't seem obvious, but look at the stack trace in #1607, for thread 24, yay !).

So if you have no(t too many) objections, I'll consider that merged, and use the deprecated warnings that will show up to take a deep hard look at our deadlock problems, and do a PR with that. Right now I just feel it's too painful to debug anything when you end up deadlocked by something completely unrelated.