On Fri, May 25, 2001 at 12:18:53PM -0400, Kirill wrote:
> Sorry I wasn't too clear in my initial message.
[...]
I think the blame's mine for rushing through your message.
An interface for removable alarms was documented on the list about two
years ago, but I never got around to implementing it. I've excerpted
that message here and in the TODO file so people can comment on it
before I start coding.
I'll be adding other suggestions from this list to the TODO file in
the next few days so I can move those messages out of my inbox.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
-----------------------
Improve Alarm Interface
-----------------------
> 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($time, $event, @etc);
> | $kernel->alarm_adjust($alarm_id, $seconds_to_adjust);
> | $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($seconds, $event, @etc);
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 would be depreciated. Perhaps it would be
reimplemented as a layer atop the new interface, for compatibility,
and then be depreciated.
-End-
