+1 Just out of curiosity, "when not developing on a current linux kernel." -- what is a non-current kernel? I.e., from what version is it safe use the signalfd? The oldest version we currently use is the latest 2.6.27.
Regards /Joachim On Sat, Nov 14, 2009 at 1:24 AM, Marc Lehmann <[email protected]> wrote: > I'd wish to ask you what you think about disabling signalfd usage by > default. > > Here are the pros of signalfd: > > - signal handling becomes very easy and efficient > - it is simple to use signals from multiple loops (when one requires signalfd) > - it would make it possible to implement realtime signals later > using this approach, without having to queue data in a signal handler (which > is hard). > > And here is the contra: > > signalfd usage requires blocking the signal handlers. unlike setting > signal handlers to IGN, many programs don't expect this, and since the > signal mask is inherited at exec time, this can lead to subprograms > not handling signals as expected. > > While I personally enjoy signalfd very much, the potential for problems is > imho large, as the problem is subtle and might go unnoticed, especially > when not developing on a current linux kernel. > > So what do you think, should signalfd usage be requested explicitly and > otherwise not be used? > > If we adopt this, then I would change libev to have these creation flags: > > #define EVFLAG_NOSIGFD 0U // for compatibility > #define EVFLAG_SIGFD 0x00400000U // to request signalfd support > > Ideas? > > -- > The choice of a Deliantra, the free code+content MORPG > -----==- _GNU_ http://www.deliantra.net > ----==-- _ generation > ---==---(_)__ __ ____ __ Marc Lehmann > --==---/ / _ \/ // /\ \/ / [email protected] > -=====/_/_//_/\_,_/ /_/\_\ > > _______________________________________________ > libev mailing list > [email protected] > http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev > _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
