>>>>> "GY" == Gaal Yahas <[EMAIL PROTECTED]> writes:
>> sub alarm ($secs) {
>> { sendsignal $*PID, Signal::ALARM }.cue(:delay($secs));
>> }
>>
>> Though I suppose people really mostly just want something like
>>
>> sub alarm ($secs) {
>> { sendsignal $*PID, Signal::ALARM }.delay($secs);
>> }
>>
>> The actual verb/adverb names are negotiable, but they need to handle
>> relative vs absolute times intuitively. Different words have different
>> connotations in that regard. "delay" is definitely relative, while
>> "after" tends toward absolute, though can be used relatively too.
>> "at" is definitely absolute time, but maybe too overloaded with
>> positional meanings. "later" is unfortunately completely ambiguous.
GY> We also want repeat events; I can think of two ways to do it. Either
GY> require everything to be explicit with adverbs, or have the closure's
GY> return value determine whether to keep calling back or to quit. GLib
GY> does the latter, and there's a cleanliness in how the closure itself can
GY> control when to stop, but the former means you can schedule arbitrary
GY> code without changing it.
GY> Is there anybody from the perl-loop gang around here? I'm sure they've
GY> thought about these things a lot.
i do a fair amount of event loop stuff in perl and have worked on
various apis for it. i have a few rfc's which try to tie in timers and
signals and async io with perl6's i/o functions (none of which are
defined yet).
the good news is that parrot will be providing a clean core event loop
mechanism using native kernel threads and event queues.
what a proper event loop program needs is an event loop run core or
module. it would block on reading the event queue and dispatch events
(via callbacks) as they get read in.
also you need to let go of flow control to an event loop. otherwise you
will be running 100% cpu until you block hard and the event loop can't
run again. the problem is that if you use callbacks and no threads, you
must have an event loop take over. parrot will not offer this directly
but it will be easy to create one on top of the event queue it
provides.
most uses of simple alarms now are sleep timers and breaking out of
blocking calls with die. anything more complex (even 2 timers at one
time) need a proper event loop and proper control over creating and
handling them.
signal handling can be a subset of the event loop (which is good, as
that means they can get delivered synchronously and not be a worry like
they used to be in p5 without event loops).
so the biggest difference with larry's api is that you need to specify a
callback (method or code ref or either?) in the call that sets up a
timer. and you need several options so it should be a key/value api with
good defaults. here are some of the useful options (see Event.pm for
where this is mostly from).
the problem with signal alarm is that it doesn't have any way to handle
the extra options without major pain.
callback code ref, closure, method (and object in diff
arg) or Signal::ALARM.
this could have a default like ::timer_handler
delay MINIMUM delay before timer gets triggered
at absolute time. converted internally to delay
interval repeat interval. if this is set and delay isn't,
the first delay will be this interval. this gets
you a simple repeating trigger.
hard this is useful boolean but can be tricky to explain. a
hard timer doesn't count the time used in the
callback. its intervals are hard (i.e. always 5
seconds). a soft timer counts the interval from
when the callback returns. so it is 5 seconds
plus callback time as the interval.
object callback to this object (forces the callback to
be method name).
Event.pm has a single callback arg, either a sub name or code ref or a
anon array with a method and object.
so the api could be as simple as this (p5ish style):
sub timer_handler {
say 'my time has come!'
}
set_timer_handler( interval => 5.0 ) ;
main_event_loop() ;
note the use of the default callback sub name.
a more complex one:
method timer_method {
say 'my time has come!'
}
set_timer_handler( callback => timer_method, object => $obj, interval => 5.0 ) ;
main_event_loop() ;
also the set_timer func returns a handle to manage the timer. then you
can reset it (reset the timer to 0 for this interval. useful for i/o
activity monitoring), disable/enable it and shut it down. so i would say
the returned thing should be an event object with those (and other)
methods. this implies a core Event class to handle this common stuff.
and integrating with other event loops (GUI ones in particular) is
handled by creating Event::EventLoopofChoice wrapper modules with the
same api as the core perl event class.
related topics include using events and continuations/coroutines instead
of callbacks. this means a yield type of func is needed (return is yeild
in typical event loops).
uri
--
Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
