Bruno Haible <br...@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