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