[launchd-dev] libdispatch threads, blocked SIGINT and child process

[Thomas Clement]

On 3 déc. 2010, at 10:58, Dave Keck wrote:

>> ... however the child process is still running, consuming lots of cpu (and its ppid is now 1 which is weird).
> 
> That's standard Unix behavior when a process' parent dies – it's
> reparented by the init process. On OS X, that's the system-wide
> launched instance.

Ok. I expected its new parent to be the per-user launchd instance instead.

>> I have noticed that libdispatch calls pthread_sigmask() when creating new threads blocking many signals. I have found that calling pthread_sigmask() in my dispatch_asynced code to unblock the SIGINT signal fixes the issue (the child process is also terminated when doing a ctrl-c in my Terminal window).
> 
> I would expect GCD to do some thread-preparation before it starts
> dequeueing work from queues; I'm not surprised that setting up the
> thread's signal mask is part of that preparation.
> 
> Considering the main goal of GCD is to abstract away the whole notion
> of threads, I would consider any property of a GCD thread to be
> immutable (such as those manipulated with the pthread_* APIs.)

It turns out the man page of dispatch_queue_create() specifically lists the pthread_* calls which are compatible with GCD.
pthread_sigmask() is one of them (the thread must be restored to its original state before returning though).

>> So, what do you guys think?
> 
> To accomplish your goal, I imagine I would simply use the posix_spawn
> APIs to safely spawn the process from the GCD queue without the need
> to muck with the GCD thread's state; see posix_spawnattr_setsigmask().

Right, I didn't know about that API :)
It seems the other solution is to call pthread_sigmask() between my fork() and exec() to unblock the SIGINT signal.

> Alternatively, you could spawn a thread to be designated the "fork
> thread", which could be configured with the appropriate signal mask
> and whatever other attributes. Using a simple queueing mechanism and
> the appropriate synchronization, your GCD blocks can communicate with
> the fork thread to instruct it to spawn the necessary process, which
> inherits the configured signal mask and whatever other state.

Right but it kind of defeats the point of using GCD ;)


Thanks!
Thomas