I think you should break this up into two.
One is multiple timers. The other is how AIO uses the timers.
The need for timers is independent of AIO.
I see something better than the single ALRM timer a plus. I've had
to write this capablity several times. A serious flaw in the unix
design.
<chaim>
>>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> Timers and Timeouts
PRL> =head1 ABSTRACT
PRL> This RFC will discuss supporting multiple independent timers and
PRL> timeouts for asynchronous I/O events and exiting eval blocks.
PRL> =head1 DESCRIPTION
PRL> Currently the only asynchronous timer mechanism in Perl is the alarm
PRL> signal. It has many flaws including being delivered unsafely and that
PRL> there is only one of them (which precludes nesting calls with their own
PRL> timeouts).
PRL> Under the asynchronous I/O (AIO) system all calls which support a
PRL> callback can also have an optional timeout. This event has a simple
PRL> common set of attribute/value arguments that can be used with any AIO
PRL> call. When no activity occurs on that AIO object before the timeout
PRL> period ends, the timeout is triggered and a callback is made. When any
PRL> activity occurs, the timeout is reset to its initial period (which can
PRL> also be done with the timeout_reset method). Standalone timeouts with no
PRL> AIO object can be created for use as independent timers.
PRL> Timers can be used to break out of any AIO operation and even out of
PRL> eval blocks by having the callback execute die (or quit or whatever). So
PRL> you can nest eval blocks and have control over how long each level takes
PRL> to run. Also this means no more collisions with sharing alarm calls.
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
