Re: Unix signals in GLib


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).  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.

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]