I don't understand the purpose of "ncalls" in the evsignal code:
* For normal signals, the kernel simply keeps a bitmask of
undelivered signals. So ncalls is lossy - if the signal isn't
delivered by the kernel before another one arrives, one is "lost".
Since signals are currently blocked basically any time not in poll(),
this is extremely likely if the process is busy. In practice, I
generally see normal signals used in places where this bitmask is
appropriate - "reread your configuration file and check for log
rotation", "terminate", etc. It's not important how many of these
events were received; only that a signal is delivered some time after
the latest one.
* Realtime signals are actually queued, but they come with a bunch
more information (siginfo_t) which libevent discards. I'm not sure
what purpose individual delivery would serve without this extra per-
delivery structure.
Is anyone using this feature? I'm tempted to remove it. If there's
interest, I'd be happy to write a patch that does the following:
(1) removes all the "ncalls" stuff
(2) removes the signal blocking/unblocking stuff (signal_(recalc|
deliver)) and makes signal_(add|del)() do their own work.
(3) reorders evsignal_process() slightly to make it correct when
running with unblocked signals. (I'll also describe this in more
detail.)
The goal being simplicity, and a maybe a touch more speed. (The
signal blocking/unblocking means unnecessary system calls.)
--
Scott Lamb <http://www.slamb.org/>
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
