Joshua N Pritikin wrote:
>Huh? Can you prove this? If so then it's a bug.
It's something we discussed some months ago. You said it wasn't a
bug, though I said it was. I also said that the similar problem with
$w->pending() was a bug. You pointed at Event::_queue_pending() as the
way for me to get the behaviour I wanted, which is why I documented it.
To summarise the debate we had: I argued that asynccheck()
(Event::_queue_pending()) should be called implicitly at various
points so that signals would always be handled according to the watcher
configuration at the time the signal was received. I argued that this
would be good because it would simplify the interface. You, on the other
hand, argued that asynccheck() should be called only when unavoidable,
and that this was in the interests of simplicity, but from a different
point of view.
>As far as I can tell from the code, signal counting starts when the
>watcher is started. When the watcher is stopped, any pending counted
>signals are zero'd.
If you already have a signal watcher, and then start a second one for
the same signal, the counting continues unaffected by the start of
the second watcher. Both watchers will generate events for a signal
received shortly before the second one was started. Test program from
message <[EMAIL PROTECTED]>:
#!/usr/bin/perl
use warnings;
use strict;
use Event;
Event->signal(signal => "USR1",
cb => sub { print "handler 0 got hits=", $_[0]->hits, "\n"; });
kill "USR1" => 0;
Event->signal(signal => "USR1",
cb => sub { print "handler 1 got hits=", $_[0]->hits, "\n"; });
kill "USR1" => 0;
Event::loop;
If "Event::_queue_pending();" is added to the program, immediately before
the creation of the second watcher, then it produces different output.
Incidentally, the zeroing of signal counts when a signal watcher is
stopped is not really necessary. The _queue_pending() that is needed
to work around the problem described above also solves that problem.
Here's another test program that simulates the problem I originally had
with a SIGTSTP handler which led to that discussion:
#!/usr/bin/perl
use warnings;
use strict;
use Event;
my $w;
$w = Event->signal(signal => "USR1", cb => sub {
print "handler got hits=", $_[0]->hits, "\n";
kill "USR1" => 0;
$w->stop;
$w->start;
});
kill "USR1" => 0;
Event::loop;
In Event version 0.87 the handler is invoked repeatedly: each signal
sent by the handler remains in the counts while the watcher is stopped
and restarted, and triggers another event next time round the loop.
Event version 1.00 clears the signal count when the watcher is stopped,
and so discards the received signal, producing the intended output.
If "Event::_queue_pending();" is added immediately before "$w->start;",
the behaviour is as intended in either version.
-zefram
