Good morning!
I started writing the new alarm functions from the TODO document, and
then I realized nobody has had a chance to look at the changes after
Kirill's suggestions.
Here's a copy of the newest alarms notes. I'm only implementing
alarm_set(), alarm_adjust(), and alarm_remove() until people have had
a chance to comment on the rest.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
-----------------------
Improve Alarm Interface
-----------------------
Swapped event/time in alarm_set() and event/seconds in delay_set()
based on feedback from Kirill.
Added alarm_remove_all() to clear all alarms, based on feedback from
Kirill. I'm not sure how useful this one will be.
> From [EMAIL PROTECTED] Thu Mar 18 09:20:36 1999
> Message-Id: <[EMAIL PROTECTED]>
> From: "Rocco Caputo" <[EMAIL PROTECTED]>
> To: "The POE Mailing List" <[EMAIL PROTECTED]>
> Date: Thu, 18 Mar 99 09:17:02 -0500
> Subject: TODO: fix alarms
>
> [...] If there are no objections, this will go into 0.07_01 or so,
> depending on my schedule. [...]
>
> | ***fix alarm semantics (in a way that does not break things)
> |
> | That's easy to say, anyway. How about depreciating &Kernel::alarm
> | and &Kernel::delay, and adding these functions?
$alarm_id = $kernel->alarm_set($event, $time, @etc);
$status = $kernel->alarm_adjust($alarm_id, $seconds_to_adjust);
$status = $kernel->alarm_remove($alarm_id);
> | Also the delay shortcut, which would return an ID usable by
> | &Kernel::alarm_adjust and &Kernel::alarm_remove:
> |
> | $alarm_id = $kernel->delay_set($event, $seconds, @etc);
To remove all alarms for a given event or time. I'm not sure how
useful these are yet.
$status = $kernel->alarm_remove_by_event($event);
$status = $kernel->alarm_remove_by_time($time);
To remove all alarms for the current session:
$status = $kernel->alarm_remove_all();
Should alarm_remove() be alarm_remove_by_id() ?
Needless to say, this didn't make it into 0.07_01 (see the CHANGES
file for what did). Anyway, the interface seems to have survived the
test of time: I still like it, and so do others who have seen it.
Internally, I'd maintain yet another hash: %kr_alarm_id_to_time, which
would be keyed on alarm ID and contain the corresponding alarm time
for that ID. The alarm_xyz() methods would manage the time: adjust
would adjust it, etc., so it always matches the time in the queue.
The implementation can reuse the linear/binary seek code from
_enqueue_alarm to find alarms by time (id->time lookup above) and
remove/add/adjust alarms relatively quickly. Ideally, though, it's
possible to schedule delayed alarm queue sweeps. I'd like to try that
after some more planning. See "Delay Garbage Collection" elsewhere in
this file.
The old alarm interface might be depreciated. Perhaps it could be
reimplemented as a layer atop the new interface, for compatibility,
and then be depreciated.
