[libdispatch-dev] Clarification on default target_queue for custom serial queues

[DrPizza]

> it is this 'true' here that makes all the difference, the default target
> queue of a serial queue is the _overcommit_ default-priority global
> concurrent queue.
> 
> For items/queues submitted to an overcommit global queue, the current Mac OS
> X kernel workqueue mechanism creates threads more eagerly, e.g. even if an n-
> wide machine is already fully committed with n cpu-busy threads, submitting
> another item directly to the overcommit global queue or indirectly to a
> serial queue with default target queue will cause another thread to be
> created to handle that item (potentially overcommitting the machine, hence
> the name).
> 
> If you wish to avoid this, simply set the target queue of your serial queues
> to the default priority global queue (i.e. non-overcommit).
> 
> The overcommit/non-overcommit distinction is intentionally undocumented and
> only available in the queue_private.h header because we hope to revise the
> kernel workqueue mechanism in the future to avoid the need for this
> distinction.

Do the present non-overcommit queues still do the Right Thing if all threads are currently non-busy-but-blocked? In other words, will they let me deadlock by submitting N units of work that require the N+1th to succeed (with N+1 being kept on the queue because the system won't spin up any more threads)? I know there is specific language about this situation in the code (for codepaths that use raw pthreads rather than workqueues), but I'm not sure how the workqueue situation is handled.