Also for the record, this is the exact behaviour of the portable libpthread_workqueue implementation uses on other platforms as well. Cheers, Joakim This email was sent from my iPhone, so it may be unusually terse. On 26 jun 2011, at 02:14, "Daniel A. Steffen" <dsteffen@apple.com> wrote:
On Jun 25, 2011, at 5:08 PM, DrPizza wrote:
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.
yes, blocked threads are handled differently than cpu-busy ones, even on the non-overcommit workqueues new threads will be created if there are blocked threads (and fewer than than n cpu-busy threads for a n-wide machine).
The kernel imposes an overall limit to the total number of workqueue threads per process, so if N is too large you can still deadlock yourself by blocking too many threads.
Daniel
_______________________________________________ libdispatch-dev mailing list libdispatch-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev