On Mon, Jun 04, 2001 at 07:11:27PM -0400, Kirill wrote:
> alarm_adjust causes the alarm queue to go out of order (time-wise),
> so alarms don't get delivered on time, and the alarm search fails
> sooner or later.
I'd like to fix this right away. Can you provide a small test case?
> The workaround is to use alarm_remove and alarm_set instead.
>
> Is it normal for alarm time to become negative? When it says
>
> *** Alarm times: ...
This message's alarm times are offset from time(), and it's normal to
see negative values. This means the event loop is lagging behind
alarm dispatch, possibly because a previous event handler took too
long, because the time between alarms is faster than the loop can
dispatch, or because an alarm was set or adjusted into the past.
The select() timeout code is designed to handle negative values; if
there is a problem, I'll need to verify that and fix it right away.
> sometimes one or more of the alarms in the queue show negative
> time. Then POE dispatches a few select_* events, and only after
> that it dispatches the alarm event. Is this normal?
Yes, this is normal. Timed events are implemented in terms of
select() so that code like this won't prevent file activity from
generating events:
sub alarm_event_handler {
$_[KERNEL]->delay( alarm_event => -1 );
}
If the select() loop didn't poll filehandles in this case, then the
main loop would busy itself with alarm dispatches to the exclusion of
file events.
See &substrate_main_loop in POE/Kernel/Select.pm for the code that
coordinates select(), alarms, and posted events.
> By the way, the http://poe.sourceforge.net/packages/POE.ppd
> file currently points to POE version 0.13.
The PPD is maintained by the volunteer efforts of Douglas Couch, and
it tends to lag slightly behind the .tar.gz distribution.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
