Re: data structures for use in signal handlers

[Eric Wong]

Bruno Haible <bruno@clisp.org> wrote:
> Eric Wong wrote:
> > > How would setting up a pipe or eventfd help with a communication
> > > problem between threads in the same process? I thought these were
> > > for communication between processes.
> > 
> > The "self-pipe trick" is a common idiom in Unix for signal
> > handling; especially when pselect/ppoll aren't available.
> > I seem to recall learning of it reading something by djb.

> What I understand from [1] is that if a program uses signals AND
> select()/poll(), then it is useful to map signals into events that
> can be received by select()/poll(). The self-pipe trick is a way
> to do that.

Right.

> Maybe I didn't describe accurately the situation I am asking for.
> I'm not attempting to transform a program to an event-based engine.
> I'm looking to let signal handlers (SIGTERM, SIGSEGV, SIGWINCH, etc.)
> read and traverse data structures that the main program has prepared
> (and that contain information about files to delete, memory areas,
> window lines to redraw etc.).

No worries, I figured pipes/sockets weren't an options given
your mention of libsigsegv in the original post.

One possible solution is to spawn a dedicated thread which does
nothing but run an event loop to handle signals sequentially
without reentrancy.  Then, signal handlers are guaranteed to run
alone and existing thread-safe structures (e.g. rculfhash) and
locks would be able to work properly.

It all depends on whether you can spawn a dedicated thread for
that.  FWIW, liburcu uses background threads internally, too.


> [1] http://osiris.978.org/~alex/safesignalhandling.html