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

Dave Zarzycki zarzycki at apple.com
Thu Jul 7 19:11:30 PDT 2011

On Jul 7, 2011, at 5:11 PM, Mark Heily wrote:

> On a related note, here's an interesting question about installing a signal handler for SIGSEGV in a libdispatch-based program. I haven't tried this, but does anyone know if it's possible to install a signal handler for SIGSEGV that would be propagated to all of the GCD worker threads?


Yes, that is how signals work. Also, for all *practical* purposes, GCD makes POSIX signals *more* reliable than they normally are. What GCD does is route externally generated signals (SIGHUP, SIGTERM, SIGPIPE, SIGUSR1, etc) away from GCD threads (and if need be, a dedicated signal handling thread). Why does GCD doe this? Because signal handlers are difficult to program correctly. They cause unrelated subsystems to experience spuriously system call failures (EINTR) and deadlocks are easily to trip over due to the fact that signal handlers pause a random thread in order run on that thread's stack. In contrast, GCD has signal event sources that avoid the aforementioned problems.

Also, one should keep in mind that one can always use pthread_sigmask() to unmask the signals that GCD masks by default for GCD threads. The rules are documented in dispatch_queue_create(3) under the COMPATIBILITY section:

     Applications MAY call the following interfaces from a block submitted to
     a dispatch queue if and only if they restore the thread to its original
     state before returning:

           o   pthread_setcancelstate()

           o   pthread_setcanceltype()

           o   pthread_setschedparam()

           o   pthread_sigmask()

           o   pthread_setugid_np()

           o   pthread_chdir()

           o   pthread_fchdir()


More information about the libdispatch-dev mailing list