Re: Unix signals in GLib

[Stef Walter <stef-list memberwebs com>]

On 2010-05-01 16:22, Ray Strode wrote:
> Hi,
> 
> On Fri, Apr 30, 2010 at 11:51 AM, Stef Walter <stef-list memberwebs com> wrote:
>>> Could you give more details please? Thanks.
>>
>> For reasons that are almost, but not entirely, clear to me you have to:
>>
>>  1. Block signals you're interested in on all threads, usually done
>>    early on, before starting any threads. Using pthread_sigmask.
>>  2. Unblock those signals in a new purpose specific thread, and call
>>    sigwait in that thread, in a loop, handling signals as they come in.
>> This is partly due to the fact that signals will be delivered on random
>> threads in a multi-threaded app.
> Right, there's no way to say "send all signals to this specific
> thread" with blocking those signals explicitly in all other threads.
> This is because it's completely random which thread a signal will get
> delivered to in a process.
> 
>> But there's another reason I don't
>> completely understand, because if that was the only reason, then it
>> seems the writing to a socketpair should work.
> Using a socketpair (or even better a pipe) should work fine
> (especially if block signal delivery to all but one thread).  

Maybe that was the problem with the previous implementation in
gnome-keyring: We didn't block signals on any threads.

Were you
> writing multiple bytes down the wire per signal?  Remember signals can
> fire recursiviely, preempting a signal handler already running, so you
> should keep the write call one byte, if possible, so that it's
> atomically written to the socket or pipe.

Yup, just one byte per signal invocation.

> Also, linux has signalfd() now which (while not portable) means you
> can skip the whole socket/pipe thing all together.  It just gives you
> a file descriptor you can add to the mainloop.

Interesting. Nice.

Cheers,

Stef