On Sat, 14 Nov 2009 01:24:36 +0100 Marc Lehmann <schm...@schmorp.de> 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? > a selfish +1 for not using signalfd by default (multiprocessing in python is a bit more difficult to use when signals are blocked in children) malek _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
