1Event(3) User Contributed Perl Documentation Event(3)
2
6 Event - Event loop processing
7
9 use Event qw(loop unloop);
10 # initialize application
12 Event->flavor(attribute => value, ...);
13 my $ret = loop();
15 # and some callback will call
17 unloop('ok');
18
20 The Event module provide a central facility to watch for various types
21 of events and invoke a callback when these events occur. The idea is
22 to delay the handling of events so that they may be dispatched in pri‐
23 ority order when it is safe for callbacks to execute.
24 Events (in the ordinary sense of the word) are detected by watchers,
26 which reify them as events (in the special Event module sense). For
27 clarity, the former type of events may be called "source events", and
28 the latter "target events". Source events, such as signals arriving,
29 happen whether or not they are being watched. If a source event occurs
30 which a watcher is actively watching then the watcher generates a cor‐
31 responding target event. Target events are only created by watchers.
32 If several watchers are interested in the same source event then each
33 will generate their own target event. Hence, any particular source
34 event may result in zero, one, two, or any number of target events: the
35 same as the number of watchers which were actively watching for it.
36 Target events are queued to be processed in priority order (priority
38 being determined by the creating watcher) and in FIFO order among
39 events of the same priority. Queued ("pending") events can, in some
40 cases, be cancelled before being processed. A queued event is pro‐
41 cessed by being passed to the callback function (or method on a partic‐
42 ular object or class) which was specified to the watcher.
43 A watcher, once created, operates autonomously without the Event user
45 having to retain any reference to it. However, keeping a reference
46 makes it possible to modify most of the watcher's characteristics. A
47 watcher can be switched between active and inactive states. When inac‐
48 tive, it does not generate target events.
49 Some types of source event are not reified as target events immedi‐
51 ately. Signals received, for example, are counted initially. The
52 counted signals are reified at certain execution points. Hence, signal
53 events may be processed out of order, and if handled carelessly, on the
54 wrong side of a state change in event handling. A useful way to view
55 this is that occurrence of the source event is not actually the arrival
56 of the signal but is triggered by the counting of the signal.
57 Reification can be forced when necessary. The schedule on which some
59 other events are created is non-obvious. This is especially the case
60 with watchers that watch for a condition rather than an event. In some
61 cases, target events are generated on a schedule that depends on the
62 operation of the event loop.
63
65 Events (the occurrence of such) are noticed and queued by 'event watch‐
66 ers'. The creation and configuration of event watchers is the primary
67 topic of the rest of this document.
68 The following functions control or interrogate the event loop as a
70 whole:
71 $result = loop([$timeout])
73 Will enter a loop that calls one_event() until unloop() is called.
74 The argument passed to unloop() is the return value of loop().
75 Loops can be nested.
76 unloop($result)
78 Make the inner-most loop() return with $result.
79 unloop_all($result)
81 Cause all pending loop()s to return immediately. This is not
82 implemented with "die". It is works as if "unloop($result)" were
83 called for all nested loops.
84 sweep([$max_prio])
86 Queue all pending events and dispatch any with priority strictly
87 less than $max_prio (the highest priority is 0). The default is to
88 process all events except idle events. (While idle events are
89 ignored by sweep, idle watchers are not ignored. If you want to
90 avoid triggering an idle watcher then set "max" to "undef" or
91 "stop()" it.)
92 one_event([$timeout])
94 If any events are outstanding then invoke the corresponding call‐
95 back of the highest priority event. If there are no events avail‐
96 able, block forever or until $timeout. Use of this API is not rec‐
97 ommended because it is not efficient and does not trap exceptions.
98 However, you might wish to understand how it works:
99 1 Queue asyncronous events (signals, etc). That is, previously
101 recorded events are reified.
102 2 If there are any events with priority 5 or less (see
104 StarvePrio) then service the next one and return.
105 3 Calculate the maximum wait time (minimum time till the next
107 timer expiration) and pass control to the poll/select system
108 call. Upon return, queue all pending events.
109 4 Queue asyncronous events again.
111 5 If there are any events then service the next one and return.
113 6 Service the next idle watcher.
115 StarvePrio is the priority level for which events are dispatched
117 during step 2. It cannot be changed without a recompile. In the
118 rare case that an event is always pending at step 2 then I/O watch‐
119 ers will starve. However, this is highly unlikely since async
120 watchers should never queue events so rapidly.
121 all_watchers()
123 Returns a list of all watchers (including stopped watchers).
124 all_running()
126 Returns a list of all watchers with actively running callbacks.
127 Watchers are returned in order of most recent to least recent.
128 all_idle()
130 Returns a list of all the idle watchers. If the event queue is
131 very busy, all the idle watchers will sit on the idle queue waiting
132 to run. However, be aware that if an idle watcher has the "max"
133 attribute set then it will queue a normal event when its "max" wait
134 time is exceeded.
135 queue_pending()
137 Examines asynchronous source events (timers & signals) and reifies
138 them as target events. "queue_pending()" is only called implicitly
139 by "sweep()" and "one_event()". Otherwise, "queue_pending()" is
140 not called implicitly.
141 NOTE: Signal watchers generate target events according to which
143 watchers are active at the time that "queue_pending()" is called
144 rather than according to the time the signal is received. This is
145 best explained by example. See the file "demo/queue_pending.t".
146 Event Watcher Constructors
148 All watchers are constructed in one of the following ways:
150 $w = Event->flavor( [attr1 => $value,]... );
152 $w = Event::flavor($Class, [attr1 => $value,]...);
154 $w = Event::flavor->new([attr1 => $value,]...);
156 Where flavor is substituted with the kind of watcher. Built-in types
158 include idle, io, signal, timer, and var.
159 New watchers (hopefully) have reasonable defaults and can also be cus‐
161 tomized by passing extra attributes to the constructor. When created,
162 watcher objects are "started" and are waiting for events (see
163 "$event->start" below).
164 NetServer::Portal can display watchers in real-time, formatted simi‐
166 larly to the popular "top" program. You may find this a useful aide
167 for debugging.
168 Shared Watcher Attributes
170 Watchers are configured with attributes (also known as properties).
172 For example:
173 $watcher->cb(\&some_code); # set callback
175 warn $event->w->desc.": ".$event->hits." events happened; Wow!";
177 All watchers support the following attributes: cb, cbtime, debug, desc,
179 prio, max_cb_tm, reentrant, and repeat. Watcher constructors accept
180 the preceding and additionally: async and nice. Moreover, watchers
181 also offer extra attributes according to their specialty.
182 Shared Watcher Methods
184 The following methods are available for all watchers:
186 $watcher->start
188 Activate the watcher. Watchers refuse to "start()" without suffi‐
189 cient configuration information to generate events. Constructors
190 always invoke "start()" unless the "parked=>1" option is requested.
191 You will need to set the parked option if you preallocate unconfig‐
192 ured watchers.
193 Note: If there are any unreified asynchronous events that are of
195 interest to the watcher, it will see these events even though they
196 happened before it was started. This affects signal watchers, but
197 there will only be existing unreified signal events if Event was
198 already handling the signal, which it would only do if there were
199 another active watcher for the same signal. If this situation
200 might occur, and it would be a problem for the new watcher to see
201 older events, call "queue_pending()" immediately before starting
202 the new watcher in order to reify any outstanding events. This
203 explaination may be more clear if read along with "demo/queue_pend‐
204 ing.t".
205 $watcher->again
207 This is the same as the "start" except if a watcher has special
208 repeat behavior. For example, repeating timers recalculate their
209 alarm time using the "interval" parameter.
210 $watcher->now
212 Cause the watcher to generate an event, even if it is stopped. The
213 callback may or may not run immediately depending upon the event's
214 priority. If you must unconditionally invoke the callback, con‐
215 sider something like
216 $w->cb->($w);
218 $watcher->stop
220 Don't look for events any more. Running events are allowed to com‐
221 plete but pending events are cancelled. Note that a stopped
222 watcher can be reactivated by calling the "start" or "again" meth‐
223 ods.
224 Watchers are stopped implicitly if their new configuration deprives
226 them of the ability to generate events. For instance:
227 my $io_watcher = Event->io(timeout => 1); # started
229 $io_watcher->timeout(undef); # stopped implicitly
230 $io_watcher->timeout(1); # still stopped
231 $io_watcher->start; # restarted
232 $watcher->cancel
234 Stop and destroy $watcher. Running events are allowed to complete
235 but pending events are cancelled. Cancelled watchers are no longer
236 valid except for read-only operations. For example, prio() can
237 return the watcher's priority, but start() will fail.
238 $watcher->is_cancelled
240 Reports whether the $watcher has been cancelled.
241 $watcher->is_active
243 Reports whether the $watcher has been started. The return value is
244 not affected by suspend.
245 $watcher->is_running
247 Zero if the callback is not running. Otherwise, the number of lev‐
248 els that the callback has been entered. This can be greater than
249 one if a "reentrant" callback invokes "loop" (or "sweep", with
250 lesser probability).
251 $watcher->is_suspended
253 Reports whether the $watcher is suspended. Suspension is a debug‐
254 ging feature; see the discussion of the "suspend" attribute below.
255 $watcher->pending
257 In scalar context, returns a boolean indicating whether this
258 watcher has any events pending in the event queue. In array con‐
259 text, returns a list of all the watcher's pending events.
260 Note that this does not check for unreified asynchronous events.
262 Call "queue_pending()" first if you want to see signals received
263 since the last operation of the event loop.
264 Watcher Types
266 idle
268 Extra attributes: min => $seconds, max => $seconds
269 Watches for the Event system to be idle, i.e., to have no events
271 pending. If the system is never idle, an event will be generated
272 at least every "max" seconds. While Event is idle, events will be
273 generated not more often than "min" seconds.
274 If neither "min" nor "max" is specified, the watcher defaults to
276 one-shot behaviour ("repeat" false), otherwise it defaults to
277 repeating. In either case, the default can be overidden by speci‐
278 fying a "repeat" attribute. "min" defaults to 0.01, and "max"
279 defaults to infinity.
280 var Extra attributes: var => \$var, poll => 'rw'
282 Var watchers generate events when the given variable is read from
284 or written to, as specified by "poll". "poll" defaults to "w".
285 As perl is a concise language, it is often difficult to predict
287 when a variable will be read. For this reason, variable watchers
288 should poll only for writes unless you know what you are doing.
289 timer
291 Extra attributes: at => $time, after => $sec, interval => $sec,
292 hard => $bool
293 Generate events at particular times. The $time and $sec are in
295 seconds. Fractional seconds may be used if Time::HiRes is avail‐
296 able. "at" and "after" are mutually exclusive.
297 "at" or "after" specify the initial time that the event will trig‐
299 ger. Subsequent timer events occur at intervals specified by
300 "interval" or "after" (in that order of preference) if either was
301 supplied. The timer defaults to one-shot behaviour if "interval"
302 was not specified, or repeating behaviour if "interval" was speci‐
303 fied; in either case this can be overridden by providing "repeat"
304 explicitly.
305 You need to know the time at the start of today if you are trying
307 to set timers to trigger at day relative times. You can find it
308 with:
309 use Time::Local;
311 my $TodaySeconds = int timelocal(0,0,0,(localtime)[3,4,5]);
312 This calculation may seem a little heavy weight. If you want to
314 use UTC rather than local time then you can use this instead:
315 my $TodaySeconds = time - time % 86400;
317 Beware that, due to lags in the event loop, the "interval" timeout
319 may already be in the past. If the "hard" flag is set, the event
320 will be queued for execution relative to the last time the callback
321 was invoked. However, if "hard" is false the new timeout will be
322 calculated relative to the current time. "hard" defaults to false.
323 io Extra attributes: fd => $fd, poll => 'rwe' [timeout => $seconds,
325 hard => $bool, timeout_cb => \&code]
326 The callback is invoked when the file descriptor, "fd", has data to
328 be read, written, or pending exceptions. "fd" can be a GLOB, an
329 IO::Handle object, or a file number (file descriptor). "poll"
330 defaults to "r".
331 Note that it is your option whether to have multiple watchers per
333 file handle or to use a single watcher for all event conditions.
334 If "timeout" is set, events are also generated regularly if no
336 actual I/O event occurs. If "timeout_cb" is set then timeouts use
337 this alternate callback instead of the main callback.
338 signal
340 Extra attribute: signal => $str
341 Generates events based on signal arrival. The events are not actu‐
343 ally generated immediately when the signal arrives: signals
344 received are counted and reified by "queue_pending()" or implicitly
345 by "one_event()". Several signals of the same type may be merged
346 into a single event. In such cases, the number of signals repre‐
347 sented by a single event is stored in the "hits" attribute.
348 PRIORITY
350 Priority is used to sort the event queue. Meaningful priorities range
352 from -1 to 6 inclusive. Lower numbers mean higher priority (-1 is the
353 highest priority and 6 is the lowest). If multiple events get queued,
354 the ones with the highest priority are serviced first. Events with
355 equal priority are serviced in first-in-first-out order.
356 use Event qw(PRIO_HIGH PRIO_NORMAL); # some constants
358 LEVELS: -1 0 1 2 3 4 5 6
360 ----------------------+-------------+---------------
361 PRIO_HIGH PRIO_NORMAL
362 A negative priority causes the callback to be invoked immediately upon
364 event occurrence. Use this with caution. While it may seem advanta‐
365 geous to use negative priorities, they bypass the whole point of having
366 an event queue.
367 Each watcher has a default priority, assigned by its constructor:
369 io PRIO_NORMAL
371 signal PRIO_HIGH
372 timer PRIO_NORMAL
373 var PRIO_NORMAL
374 Default priorities are stored in ${"Event::${type}::DefaultPriority"}.
376 If the default priority is not satisfactory for your purposes, the con‐
377 structor options "nice", "async", or "prio" can be used to adjust it.
378 "nice" specifies an offset from the default priority; "async" forces
379 the priority to -1; and "prio" assigns a given priority of your choice.
380 If more than one of these options are given then "prio" overrides
381 "async" overrides "nice".
382 WATCHER CONSTRUCTOR ATTRIBUTES
384 These options are only supported as constructor arguments.
386 after => $seconds
388 See the discussion of the timer watcher.
389 async => $bool
391 If $bool then the watcher priority is set to -1.
392 nice => $offset
394 Offset from the default priority.
395 parked => $yes
397 By default, watcher constructors automatically invoke the "start()"
398 method. If you don't want the watcher started then request
399 "parked=>1".
400 WATCHER ATTRIBUTES
402 at => $time
404 The expiration time in the same units as the system clock. For a
405 timer, "at" will usually be in the future.
406 cb => \&code
408 cb => [$class_or_object, $method_name]
409 The function or method to call when an event is dispatched. The
410 callback is invoked with $event as its only argument.
411 Perhaps you are wondering what happens if something goes wrong and
413 an untrapped "die" occurs within your callback? $Event::DIED is
414 just for this purpose. See the full description of "DIED" below.
415 cbtime => $time
417 When the callback was invoked most recently.
418 data => $anything
420 The "data()" method associates arbitrary data with a watcher.
421 This method is not intended for implementers of watchers. If you
423 are subclassing or implementing a watcher, consider the "private()"
424 method.
425 debug => $bool
427 Debugging can be activated globally or per watcher. When debugging
428 is enabled for a particular watcher, $Event::DebugLevel is treated
429 as two levels higher. Levels of 1, 2, 3, or 4 give progressively
430 more diagnostics on STDERR.
431 desc => $string
433 An identifying name. If this is not passed explicitly to the con‐
434 structor, it will be initialized with a string that attempts to
435 identify the location in the source code where the watcher was con‐
436 structed.
437 fd => $filehandle
439 This attribute can accept either a perl-esque filehandle or a sys‐
440 tem call derived file descriptor number.
441 hard => $bool
443 Determines how repeating timers (or timeouts) are recalculated.
444 The timer is restarted either before or after the callback depend‐
445 ing on whether it is true or false, respectively. In long-running
446 callbacks this can make a significant difference.
447 interval => $seconds
449 How long between repeating timeouts. The "at" attribute is recal‐
450 culated using "interval" upon callback return.
451 max => $seconds
453 The maximum number of seconds to wait before triggering the call‐
454 back. Similar to a "timeout".
455 max_cb_tm => $seconds
457 The maximum number of seconds to spend in a callback. If a call‐
458 back uses more time then it is aborted. Defaults to 1 sec. This
459 feature is normally disabled. See Event::Stats.
460 min => $seconds
462 Enforce a minimum number of seconds between triggering events.
463 poll => $bits
465 Determines which kinds of events are of interest. This attribute
466 can be set with either strings or bit constants. The bit constants
467 are available via 'use Event::Watcher qw(R W E T);'.
468 string constant description
470 ------ -------- ---------------
471 'r' R read
472 'w' W write
473 'e' E exception
474 't' T timeout
475 Thus, both of these statements enable interest in read:
477 $w->poll($w->poll . 'r');
479 $w->poll($w->poll ⎪ R);
480 A given type of watcher may support all or a subset of the avail‐
482 able events.
483 prio => $level
485 Changes the watcher's priority to the given level. Events gener‐
486 ated by a watcher usually inherit the priority of the watcher.
487 private => $anything
489 Use the "private()" method to associate arbitrary data with a
490 watcher. This method is intended for implementers of watchers or
491 watcher subclasses. Each caller's package accesses its own private
492 attribute.
493 reentrant => $bool
495 By default, callbacks are allowed to invoke "sweep" or "loop" which
496 in turn may invoke the same callback again recursively. This can
497 be useful but can also be confusing. Moreover, if you keep reen‐
498 tering callbacks you will quickly run out of stack space. Disable
499 this feature per watcher by setting reentrant to false. This will
500 cause the watcher to be suspended during recursive calls to "sweep"
501 or "loop".
502 repeat => $bool
504 The repeat flag controls whether the callback should either be one-
505 shot or continue waiting for new events. The default setting
506 depends on the type of watcher. io, signal, and var default to
507 true.
508 signal => $str
510 The callback is invoked after the specified signal is received.
511 The $str string should be something like 'INT' or 'QUIT'. Also see
512 the documentation for %SIG.
513 A given signal can be handled by %SIG or Event, but not both at the
515 same time. Event handles the signal as long as there is at least
516 one active watcher. If all watchers for the signal are cancelled or
517 stopped then Event sets the signal handler to SIG_DFL.
518 suspend => $bool
520 Stop looking for events. Running events are allowed to complete,
521 but queued events are cancelled.
522 Suspend is for debugging. If you suspend all watchers in an appli‐
524 cation then you can examine the complete state unchanged for as
525 long as you like without worrying about timer expirations. If you
526 actually wish to stop a watcher then use the "stop()" method.
527 timeout => $seconds
529 The number of seconds before a watcher times out.
530 timeout_cb => \&code
532 timeout_cb => [$class_or_object, $method_name]
533 This is an optional attribute for use when it is desired that time‐
534 outs be serviced in a separate code path than normal events. When
535 this attribute is unset, timeouts are serviced by "cb".
536 var => $ref
538 A reference to the variable being watched.
539 EVENT ATTRIBUTES
541 got => $bits
543 "got" is available in the callback of watchers with "poll". "got"
544 is in the same format as "poll" except that it gives what kind of
545 event actually happened. In contrast, "poll" is just an indication
546 of interest.
547 hits => $int
549 Signals in quick succession can be clumped into a single event.
550 The number of signals clumped together is indicated by this
551 attribute. This is always one for event types which don't clump.
552 prio => $level
554 Be aware that this priority can differ from the watcher's priority.
555 For instance, the watcher's priority may have changed since the
556 event was generated. Moreover, the C extension API offers the
557 freedom to queue events of arbitrary priority.
558 w => $watcher
560 This method return the event's watcher. It is read-only.
561 Customization and Exceptions
563 * $Event::DebugLevel
565 Enables progressively more debugging output. Meaningful levels
566 range from 1 (least output) to 5 (most output). Also see "debug".
567 * $Event::DIED
569 When "loop" or "sweep" is called, an exception context is estab‐
570 lished for the duration of event processing. If an exception is
571 detected then $Event::DIED is invoked. The default hook uses
572 "warn" to output the exception. After the DIED handler completes,
573 event processing continues as if nothing happened.
574 If you'd like more detailed output you can install the verbose han‐
576 dler:
577 $Event::DIED = \&Event::verbose_exception_handler;
579 Or you can write your own. The handler is invoked like this:
581 $Event::DIED->($event, $@);
583 If you do not want to continue looping after an error, you can do
585 something like this:
586 $Event::DIED = sub {
588 Event::verbose_exception_handler(@_);
589 Event::unloop_all();
590 };
591 * Event->add_hooks(key => sub { ... }, ...);
593 The bulk of Event's implementation is in C for maximum performance.
594 The "add_hooks" method allows insertion of perl code at key points
595 in the optimized event processing core. While flexible, this can
596 hurt performance *significantly*. If you want customization *and*
597 performance, please see the C API.
598 Currently support hooks are detailed as follows:
600 hook purpose
602 ------------- ----------------------------------------------
603 prepare returns minimum time to block (timeable)
604 check assess state after normal return from select/poll
605 asynccheck check for signals, etc
606 callback invoked before each event callback
607
609 Event also has a direct API for callbacks written exclusively in C.
610 See Event::MakeMaker.
611
613 Event loops and threads are two different solutions to the same prob‐
614 lem: asynchronous processing. Event loops have been around since the
615 beginning of computing. They are well understood and proven to be a
616 good solution for many applications.
617 While event loops make use of basic operating system services, the bulk
619 of their implementation is usually outside the kernel. While an event
620 loop may appear to do many things in parallel, it does not, even on
621 multiprocessor hardware. Actions are always dispatched sequentially.
622 This implies that long running callbacks must be avoided because other‐
623 wise event processing is halted.
624 Event loops work well when actions are short and to the point. Long-
626 running tasks must be broken into short steps and scheduled for execu‐
627 tion. Some sort of a state machine is usually required. While a big,
628 complex application server is usually simpler to implement in a multi‐
629 threaded fashion, a web browser can easily get by without threads.
630 Consider a JPEG file download and render. When some new bytes are
631 available they are sorted to the right place on the screen. Only a
632 little state must be kept to keep track of how much has been rendered
633 and to process subsequent incoming bytes.
634 Threads can either substitute for an event loop or complement it.
636 Threads are similar to processes in that the operating system manages
637 task switching for you. However, the difference is that all threads
638 share the same address space. This is good and bad. Higher perfor‐
639 mance can be achieved but since data is shared between threads, extreme
640 care must be taken to access or modify global data. The operating sys‐
641 tem can switch threads at any moment or can execute multiple threads
642 simultaneously. I hope this sounds dangerous! It is! Threads can
643 introduce maddeningly complicated and hard to debug synchronization
644 problems.
645 Threads are like rocket fuel. They are essential when you really need
647 them but most applications would be better off with a simple event
648 loop. Even if threads are genuinely needed, consider confining them to
649 the parts of an application where truly scalable performance is really
650 worth the difficulty of a multithreaded implementation. For example,
651 most GUIs applications do not need threads and most scientific compute
652 intensive problems can be isolated from event dispatching. On the
653 other hand, high performance transaction servers generally do mandate a
654 truly multithreaded approach.
655 Another consideration is that threads are not quite as widely available
657 as event loops. While a few forward-thinking operating systems have
658 offered threads since the beginning, their addition to many popular
659 operating systems is much more recent and some still offer no threads
660 support. If portability is a requirement, one must check that threads
661 support is available and also carefully test a particular threads
662 implementation to see whether it supports the features you need. It is
663 likely that all platforms will have a solid implementation soon but at
664 this point in history it is best to double check.
665 Many suggestions by Mark Mielke <Mark.Mielke.markm@nt.com>
667
669 The Java language is oriented to use non-preemptive threads, yet even
670 Java uses an event-loop for Swing (AFAIK). That is one of the reasons I
671 don't use Java for network-centric applications. My belief is that the
672 benefit of multi-threading is the gain in performance on SMP hardware.
673 In my view, non-preemptive threads (java green-threads) are usually
674 poor design. I find them harder to work with, harder to debug, and
675 slower for a rather marginal gain in readability. I really like working
676 with a state machine. I find it leads to more stable and better code.
677 It also has the benefit of abstracting away how concurrency is
678 achieved.
679 Contributed by artur@vogon-solutions.com, 12 Jul 1999.
681
683 No support for epoll, or better, libevent.
684 The scope of events is pretty strange compared to most other perl
686 objects. I'm not sure if this is a bug or a feature (OK, probably it
687 was a mistake). We'll probably want to re-work things for Perl6.
688 The meaning of $io->timeout(0) might change. Use "undef" to unset the
690 timeout.
691 There seems to be some sort of bug in the global destruction phase:
693 Attempt to free unreferenced scalar during global destruction.
695 Use of uninitialized value during global destruction.
696 Explicit blessing to '' (assuming package main) during global
697 destruction.
698
700 Even if this module does not end up being the One and True Event Loop,
701 the author will insure that it is source compatible with its successor,
702 or arrange for gradual migration. Back in the early days, the Event
703 programming API was changing at every release. Care was taken to allow
704 the old API to continue to work, and the transition was eased by print‐
705 ing out lots of warnings about the new usage. So you shouldn't sit on
706 your hands in anticipation of the One and True Event Loop. Just start
707 coding!
708
710 * Useful and Fun
711 Time::HiRes, NetServer::Portal, Time::Warp
712 * Message Passing
714 COPE, IPC::LDT, Event-tcp
715 * GUI
717 While Tk does not yet support Event, PerlQt does.
718 * C API
720 Inline
721
723 If you have insights or complaints then please subscribe to the mailing
724 list! Send email to:
725 perl-loop-subscribe@perl.org
727
729 Joshua N. Pritikin <jpritikin@pobox.com>
730
732 Initial 0.01 implementation by Graham Barr <gbarr@pobox.com>. Other
733 contributors include at least those lists below and folks mentioned in
734 the ChangeLog.
735 Gisle Aas <gisle@aas.no>
737 Uri Guttman <uri@sysarch.com>
738 Nick Ing-Simmons <nick@ni-s.u-net.com> (Tk)
739 Sarathy <gsar@engin.umich.edu>
740 Jochen Stenzel <perl@jochen-stenzel.de>
741
743 Copyright © 1997 Joshua Nathaniel Pritikin & Graham Barr
744 Copyright © 1998, 1999, 2000, 2001, 2002, 2003, 2004 Joshua Nathaniel
746 Pritikin
747 All rights reserved. This program is free software; you can redis‐
749 tribute it and/or modify it under the same terms as Perl itself.
750perl v5.8.8 2007-05-22 Event(3)