[libdispatch-dev] What's with this sigsuspend stuff?

[DrPizza]

> …but the line above is backwards. The API changes the signal mask for the
> duration of the call to that of the passed in parameter. Therefore if an
> empty set is passed in, then all signals are unblocked for the duration of
> the call.
So the uninitialized sigset_t is treated as an empty mask, allowing all signals to be delivered to the thread? OK. It still seems a little odd to me to not include the call to sigemptyset().

> To dequeue pending signals installed via signal()/sigaction() that would
> otherwise be blocked in a pure GCD app. This is because GCD threads block all
> maskable signals (see _dispatch_worker_thread() in the same file). 
It only blocks maskable signals when using raw pthreads. The pthread_workqueue implementation calls _dispatch_worker_thread2() [1], and that function doesn't touch the signal masks. Do pthread_workqueue threads block signals automatically?

And if the intent of _dispatch_pthread_sigmask() is to block maskable signals, instead of masking one by one, shouldn't it just be using sigfillset()? 

> This
> behavior helps all code that uses GCD avoid spurious EINTR errors from Unix
> system calls (which are often not tested for).
So, the (special, undocumented?) behaviour here is that if the program is determined to be "callback driven" (explicit call to dispatch_main(), or implicit use of Cocoa) then one victim workqueue thread will clear its mask and handle any signal, so that, if all other threads mask their signals, this victim thread will handle any and every signal. The value of this being that if you follow the (unwritten?) rules and mask signals from every other thread, you shouldn't then receive EINTR because you'll never have to worry about a signal being delivered to a regular thread?

OK, so nothing Windows has to worry about then. 

[1]: http://libdispatch.macosforge.org/trac/browser/trunk/src/queue.c#L1247