1Event(3)              User Contributed Perl Documentation             Event(3)
2
3
4

NAME

6       Event - Event loop processing
7

SYNOPSIS

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

DESCRIPTION

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

PERL API

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

C API

608       Event also has a direct API for callbacks written exclusively in C.
609       See Event::MakeMaker.
610

WHAT ABOUT THREADS?

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

WHAT ABOUT NON-PREEMPTIVE THREADS?

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

BUGS

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

THE FUTURE

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

ALSO SEE

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

SUPPORT

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

AUTHOR

732       Joshua N. Pritikin <jpritikin@pobox.com>
733

ACKNOWLEDGMENT

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.34.0                      2022-01-21                          Event(3)
Impressum