Re: RFC 87 (v1) Timers and Timeouts

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