ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/cvsroot/AnyEvent/README
(Generate patch)

Comparing cvsroot/AnyEvent/README (file contents):
Revision 1.59 by root, Tue Jan 5 10:45:25 2010 UTC vs.
Revision 1.63 by root, Wed Oct 13 19:49:46 2010 UTC

… …
5 Qt and POE are various supported event loops/environments. 5 Qt and POE are various supported event loops/environments.
6 6
7SYNOPSIS 7SYNOPSIS
8 use AnyEvent; 8 use AnyEvent;
9 9
10 # if you prefer function calls, look at the AE manpage for
11 # an alternative API.
12
10 # file descriptor readable 13 # file handle or descriptor readable
11 my $w = AnyEvent->io (fh => $fh, poll => "r", cb => sub { ... }); 14 my $w = AnyEvent->io (fh => $fh, poll => "r", cb => sub { ... });
12 15
13 # one-shot or repeating timers 16 # one-shot or repeating timers
14 my $w = AnyEvent->timer (after => $seconds, cb => sub { ... }); 17 my $w = AnyEvent->timer (after => $seconds, cb => sub { ... });
15 my $w = AnyEvent->timer (after => $seconds, interval => $seconds, cb => ... 18 my $w = AnyEvent->timer (after => $seconds, interval => $seconds, cb => ...);
16 19
17 print AnyEvent->now; # prints current event loop time 20 print AnyEvent->now; # prints current event loop time
18 print AnyEvent->time; # think Time::HiRes::time or simply CORE::time. 21 print AnyEvent->time; # think Time::HiRes::time or simply CORE::time.
19 22
20 # POSIX signal 23 # POSIX signal
… …
39 This manpage is mainly a reference manual. If you are interested in a 42 This manpage is mainly a reference manual. If you are interested in a
40 tutorial or some gentle introduction, have a look at the AnyEvent::Intro 43 tutorial or some gentle introduction, have a look at the AnyEvent::Intro
41 manpage. 44 manpage.
42 45
43SUPPORT 46SUPPORT
47 An FAQ document is available as AnyEvent::FAQ.
48
44 There is a mailinglist for discussing all things AnyEvent, and an IRC 49 There also is a mailinglist for discussing all things AnyEvent, and an
45 channel, too. 50 IRC channel, too.
46 51
47 See the AnyEvent project page at the Schmorpforge Ta-Sa Software 52 See the AnyEvent project page at the Schmorpforge Ta-Sa Software
48 Repository, at <http://anyevent.schmorp.de>, for more info. 53 Repository, at <http://anyevent.schmorp.de>, for more info.
49 54
50WHY YOU SHOULD USE THIS MODULE (OR NOT) 55WHY YOU SHOULD USE THIS MODULE (OR NOT)
… …
68 module users into the same thing by forcing them to use the same event 73 module users into the same thing by forcing them to use the same event
69 model you use. 74 model you use.
70 75
71 For modules like POE or IO::Async (which is a total misnomer as it is 76 For modules like POE or IO::Async (which is a total misnomer as it is
72 actually doing all I/O *synchronously*...), using them in your module is 77 actually doing all I/O *synchronously*...), using them in your module is
73 like joining a cult: After you joined, you are dependent on them and you 78 like joining a cult: After you join, you are dependent on them and you
74 cannot use anything else, as they are simply incompatible to everything 79 cannot use anything else, as they are simply incompatible to everything
75 that isn't them. What's worse, all the potential users of your module 80 that isn't them. What's worse, all the potential users of your module
76 are *also* forced to use the same event loop you use. 81 are *also* forced to use the same event loop you use.
77 82
78 AnyEvent is different: AnyEvent + POE works fine. AnyEvent + Glib works 83 AnyEvent is different: AnyEvent + POE works fine. AnyEvent + Glib works
79 fine. AnyEvent + Tk works fine etc. etc. but none of these work together 84 fine. AnyEvent + Tk works fine etc. etc. but none of these work together
80 with the rest: POE + IO::Async? No go. Tk + Event? No go. Again: if your 85 with the rest: POE + IO::Async? No go. Tk + Event? No go. Again: if your
81 module uses one of those, every user of your module has to use it, too. 86 module uses one of those, every user of your module has to use it, too.
82 But if your module uses AnyEvent, it works transparently with all event 87 But if your module uses AnyEvent, it works transparently with all event
83 models it supports (including stuff like IO::Async, as long as those use 88 models it supports (including stuff like IO::Async, as long as those use
84 one of the supported event loops. It is trivial to add new event loops 89 one of the supported event loops. It is easy to add new event loops to
85 to AnyEvent, too, so it is future-proof). 90 AnyEvent, too, so it is future-proof).
86 91
87 In addition to being free of having to use *the one and only true event 92 In addition to being free of having to use *the one and only true event
88 model*, AnyEvent also is free of bloat and policy: with POE or similar 93 model*, AnyEvent also is free of bloat and policy: with POE or similar
89 modules, you get an enormous amount of code and strict rules you have to 94 modules, you get an enormous amount of code and strict rules you have to
90 follow. AnyEvent, on the other hand, is lean and up to the point, by 95 follow. AnyEvent, on the other hand, is lean and to the point, by only
91 only offering the functionality that is necessary, in as thin as a 96 offering the functionality that is necessary, in as thin as a wrapper as
92 wrapper as technically possible. 97 technically possible.
93 98
94 Of course, AnyEvent comes with a big (and fully optional!) toolbox of 99 Of course, AnyEvent comes with a big (and fully optional!) toolbox of
95 useful functionality, such as an asynchronous DNS resolver, 100% 100 useful functionality, such as an asynchronous DNS resolver, 100%
96 non-blocking connects (even with TLS/SSL, IPv6 and on broken platforms 101 non-blocking connects (even with TLS/SSL, IPv6 and on broken platforms
97 such as Windows) and lots of real-world knowledge and workarounds for 102 such as Windows) and lots of real-world knowledge and workarounds for
… …
100 Now, if you *do want* lots of policy (this can arguably be somewhat 105 Now, if you *do want* lots of policy (this can arguably be somewhat
101 useful) and you want to force your users to use the one and only event 106 useful) and you want to force your users to use the one and only event
102 model, you should *not* use this module. 107 model, you should *not* use this module.
103 108
104DESCRIPTION 109DESCRIPTION
105 AnyEvent provides an identical interface to multiple event loops. This 110 AnyEvent provides a uniform interface to various event loops. This
106 allows module authors to utilise an event loop without forcing module 111 allows module authors to use event loop functionality without forcing
107 users to use the same event loop (as only a single event loop can 112 module users to use a specific event loop implementation (since more
108 coexist peacefully at any one time). 113 than one event loop cannot coexist peacefully).
109 114
110 The interface itself is vaguely similar, but not identical to the Event 115 The interface itself is vaguely similar, but not identical to the Event
111 module. 116 module.
112 117
113 During the first call of any watcher-creation method, the module tries 118 During the first call of any watcher-creation method, the module tries
114 to detect the currently loaded event loop by probing whether one of the 119 to detect the currently loaded event loop by probing whether one of the
115 following modules is already loaded: EV, Event, Glib, 120 following modules is already loaded: EV, AnyEvent::Impl::Perl, Event,
116 AnyEvent::Impl::Perl, Tk, Event::Lib, Qt, POE. The first one found is 121 Glib, Tk, Event::Lib, Qt, POE. The first one found is used. If none are
117 used. If none are found, the module tries to load these modules 122 detected, the module tries to load the first four modules in the order
118 (excluding Tk, Event::Lib, Qt and POE as the pure perl adaptor should 123 given; but note that if EV is not available, the pure-perl
119 always succeed) in the order given. The first one that can be 124 AnyEvent::Impl::Perl should always work, so the other two are not
120 successfully loaded will be used. If, after this, still none could be 125 normally tried.
121 found, AnyEvent will fall back to a pure-perl event loop, which is not
122 very efficient, but should work everywhere.
123 126
124 Because AnyEvent first checks for modules that are already loaded, 127 Because AnyEvent first checks for modules that are already loaded,
125 loading an event model explicitly before first using AnyEvent will 128 loading an event model explicitly before first using AnyEvent will
126 likely make that model the default. For example: 129 likely make that model the default. For example:
127 130
… …
129 use AnyEvent; 132 use AnyEvent;
130 133
131 # .. AnyEvent will likely default to Tk 134 # .. AnyEvent will likely default to Tk
132 135
133 The *likely* means that, if any module loads another event model and 136 The *likely* means that, if any module loads another event model and
134 starts using it, all bets are off. Maybe you should tell their authors 137 starts using it, all bets are off - this case should be very rare
135 to use AnyEvent so their modules work together with others seamlessly... 138 though, as very few modules hardcode event loops without announcing this
139 very loudly.
136 140
137 The pure-perl implementation of AnyEvent is called 141 The pure-perl implementation of AnyEvent is called
138 "AnyEvent::Impl::Perl". Like other event modules you can load it 142 "AnyEvent::Impl::Perl". Like other event modules you can load it
139 explicitly and enjoy the high availability of that event loop :) 143 explicitly and enjoy the high availability of that event loop :)
140 144
… …
148 callback when the event occurs (of course, only when the event model is 152 callback when the event occurs (of course, only when the event model is
149 in control). 153 in control).
150 154
151 Note that callbacks must not permanently change global variables 155 Note that callbacks must not permanently change global variables
152 potentially in use by the event loop (such as $_ or $[) and that 156 potentially in use by the event loop (such as $_ or $[) and that
153 callbacks must not "die". The former is good programming practise in 157 callbacks must not "die". The former is good programming practice in
154 Perl and the latter stems from the fact that exception handling differs 158 Perl and the latter stems from the fact that exception handling differs
155 widely between event loops. 159 widely between event loops.
156 160
157 To disable the watcher you have to destroy it (e.g. by setting the 161 To disable a watcher you have to destroy it (e.g. by setting the
158 variable you store it in to "undef" or otherwise deleting all references 162 variable you store it in to "undef" or otherwise deleting all references
159 to it). 163 to it).
160 164
161 All watchers are created by calling a method on the "AnyEvent" class. 165 All watchers are created by calling a method on the "AnyEvent" class.
162 166
163 Many watchers either are used with "recursion" (repeating timers for 167 Many watchers either are used with "recursion" (repeating timers for
164 example), or need to refer to their watcher object in other ways. 168 example), or need to refer to their watcher object in other ways.
165 169
166 An any way to achieve that is this pattern: 170 One way to achieve that is this pattern:
167 171
168 my $w; $w = AnyEvent->type (arg => value ..., cb => sub { 172 my $w; $w = AnyEvent->type (arg => value ..., cb => sub {
169 # you can use $w here, for example to undef it 173 # you can use $w here, for example to undef it
170 undef $w; 174 undef $w;
171 }); 175 });
… …
202 206
203 The I/O watcher might use the underlying file descriptor or a copy of 207 The I/O watcher might use the underlying file descriptor or a copy of
204 it. You must not close a file handle as long as any watcher is active on 208 it. You must not close a file handle as long as any watcher is active on
205 the underlying file descriptor. 209 the underlying file descriptor.
206 210
207 Some event loops issue spurious readyness notifications, so you should 211 Some event loops issue spurious readiness notifications, so you should
208 always use non-blocking calls when reading/writing from/to your file 212 always use non-blocking calls when reading/writing from/to your file
209 handles. 213 handles.
210 214
211 Example: wait for readability of STDIN, then read a line and disable the 215 Example: wait for readability of STDIN, then read a line and disable the
212 watcher. 216 watcher.
… …
235 239
236 Although the callback might get passed parameters, their value and 240 Although the callback might get passed parameters, their value and
237 presence is undefined and you cannot rely on them. Portable AnyEvent 241 presence is undefined and you cannot rely on them. Portable AnyEvent
238 callbacks cannot use arguments passed to time watcher callbacks. 242 callbacks cannot use arguments passed to time watcher callbacks.
239 243
240 The callback will normally be invoked once only. If you specify another 244 The callback will normally be invoked only once. If you specify another
241 parameter, "interval", as a strictly positive number (> 0), then the 245 parameter, "interval", as a strictly positive number (> 0), then the
242 callback will be invoked regularly at that interval (in fractional 246 callback will be invoked regularly at that interval (in fractional
243 seconds) after the first invocation. If "interval" is specified with a 247 seconds) after the first invocation. If "interval" is specified with a
244 false value, then it is treated as if it were missing. 248 false value, then it is treated as if it were not specified at all.
245 249
246 The callback will be rescheduled before invoking the callback, but no 250 The callback will be rescheduled before invoking the callback, but no
247 attempt is done to avoid timer drift in most backends, so the interval 251 attempt is made to avoid timer drift in most backends, so the interval
248 is only approximate. 252 is only approximate.
249 253
250 Example: fire an event after 7.7 seconds. 254 Example: fire an event after 7.7 seconds.
251 255
252 my $w = AnyEvent->timer (after => 7.7, cb => sub { 256 my $w = AnyEvent->timer (after => 7.7, cb => sub {
… …
269 273
270 While most event loops expect timers to specified in a relative way, 274 While most event loops expect timers to specified in a relative way,
271 they use absolute time internally. This makes a difference when your 275 they use absolute time internally. This makes a difference when your
272 clock "jumps", for example, when ntp decides to set your clock backwards 276 clock "jumps", for example, when ntp decides to set your clock backwards
273 from the wrong date of 2014-01-01 to 2008-01-01, a watcher that is 277 from the wrong date of 2014-01-01 to 2008-01-01, a watcher that is
274 supposed to fire "after" a second might actually take six years to 278 supposed to fire "after a second" might actually take six years to
275 finally fire. 279 finally fire.
276 280
277 AnyEvent cannot compensate for this. The only event loop that is 281 AnyEvent cannot compensate for this. The only event loop that is
278 conscious about these issues is EV, which offers both relative 282 conscious of these issues is EV, which offers both relative (ev_timer,
279 (ev_timer, based on true relative time) and absolute (ev_periodic, based 283 based on true relative time) and absolute (ev_periodic, based on
280 on wallclock time) timers. 284 wallclock time) timers.
281 285
282 AnyEvent always prefers relative timers, if available, matching the 286 AnyEvent always prefers relative timers, if available, matching the
283 AnyEvent API. 287 AnyEvent API.
284 288
285 AnyEvent has two additional methods that return the "current time": 289 AnyEvent has two additional methods that return the "current time":
… …
304 *In almost all cases (in all cases if you don't care), this is the 308 *In almost all cases (in all cases if you don't care), this is the
305 function to call when you want to know the current time.* 309 function to call when you want to know the current time.*
306 310
307 This function is also often faster then "AnyEvent->time", and thus 311 This function is also often faster then "AnyEvent->time", and thus
308 the preferred method if you want some timestamp (for example, 312 the preferred method if you want some timestamp (for example,
309 AnyEvent::Handle uses this to update it's activity timeouts). 313 AnyEvent::Handle uses this to update its activity timeouts).
310 314
311 The rest of this section is only of relevance if you try to be very 315 The rest of this section is only of relevance if you try to be very
312 exact with your timing, you can skip it without bad conscience. 316 exact with your timing; you can skip it without a bad conscience.
313 317
314 For a practical example of when these times differ, consider 318 For a practical example of when these times differ, consider
315 Event::Lib and EV and the following set-up: 319 Event::Lib and EV and the following set-up:
316 320
317 The event loop is running and has just invoked one of your callback 321 The event loop is running and has just invoked one of your callbacks
318 at time=500 (assume no other callbacks delay processing). In your 322 at time=500 (assume no other callbacks delay processing). In your
319 callback, you wait a second by executing "sleep 1" (blocking the 323 callback, you wait a second by executing "sleep 1" (blocking the
320 process for a second) and then (at time=501) you create a relative 324 process for a second) and then (at time=501) you create a relative
321 timer that fires after three seconds. 325 timer that fires after three seconds.
322 326
… …
411 415
412 Signal Races, Delays and Workarounds 416 Signal Races, Delays and Workarounds
413 Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching 417 Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching
414 callbacks to signals in a generic way, which is a pity, as you cannot do 418 callbacks to signals in a generic way, which is a pity, as you cannot do
415 race-free signal handling in perl, requiring C libraries for this. 419 race-free signal handling in perl, requiring C libraries for this.
416 AnyEvent will try to do it's best, which means in some cases, signals 420 AnyEvent will try to do its best, which means in some cases, signals
417 will be delayed. The maximum time a signal might be delayed is specified 421 will be delayed. The maximum time a signal might be delayed is specified
418 in $AnyEvent::MAX_SIGNAL_LATENCY (default: 10 seconds). This variable 422 in $AnyEvent::MAX_SIGNAL_LATENCY (default: 10 seconds). This variable
419 can be changed only before the first signal watcher is created, and 423 can be changed only before the first signal watcher is created, and
420 should be left alone otherwise. This variable determines how often 424 should be left alone otherwise. This variable determines how often
421 AnyEvent polls for signals (in case a wake-up was missed). Higher values 425 AnyEvent polls for signals (in case a wake-up was missed). Higher values
… …
423 saving. 427 saving.
424 428
425 All these problems can be avoided by installing the optional 429 All these problems can be avoided by installing the optional
426 Async::Interrupt module, which works with most event loops. It will not 430 Async::Interrupt module, which works with most event loops. It will not
427 work with inherently broken event loops such as Event or Event::Lib (and 431 work with inherently broken event loops such as Event or Event::Lib (and
428 not with POE currently, as POE does it's own workaround with one-second 432 not with POE currently, as POE does its own workaround with one-second
429 latency). For those, you just have to suffer the delays. 433 latency). For those, you just have to suffer the delays.
430 434
431 CHILD PROCESS WATCHERS 435 CHILD PROCESS WATCHERS
432 $w = AnyEvent->child (pid => <process id>, cb => <callback>); 436 $w = AnyEvent->child (pid => <process id>, cb => <callback>);
433 437
434 You can also watch on a child process exit and catch its exit status. 438 You can also watch for a child process exit and catch its exit status.
435 439
436 The child process is specified by the "pid" argument (one some backends, 440 The child process is specified by the "pid" argument (on some backends,
437 using 0 watches for any child process exit, on others this will croak). 441 using 0 watches for any child process exit, on others this will croak).
438 The watcher will be triggered only when the child process has finished 442 The watcher will be triggered only when the child process has finished
439 and an exit status is available, not on any trace events 443 and an exit status is available, not on any trace events
440 (stopped/continued). 444 (stopped/continued).
441 445
… …
486 $done->recv; 490 $done->recv;
487 491
488 IDLE WATCHERS 492 IDLE WATCHERS
489 $w = AnyEvent->idle (cb => <callback>); 493 $w = AnyEvent->idle (cb => <callback>);
490 494
491 Repeatedly invoke the callback after the process becomes idle, until 495 This will repeatedly invoke the callback after the process becomes idle,
492 either the watcher is destroyed or new events have been detected. 496 until either the watcher is destroyed or new events have been detected.
493 497
494 Idle watchers are useful when there is a need to do something, but it is 498 Idle watchers are useful when there is a need to do something, but it is
495 not so important (or wise) to do it instantly. The callback will be 499 not so important (or wise) to do it instantly. The callback will be
496 invoked only when there is "nothing better to do", which is usually 500 invoked only when there is "nothing better to do", which is usually
497 defined as "all outstanding events have been handled and no new events 501 defined as "all outstanding events have been handled and no new events
… …
536 540
537 AnyEvent is slightly different: it expects somebody else to run the 541 AnyEvent is slightly different: it expects somebody else to run the
538 event loop and will only block when necessary (usually when told by the 542 event loop and will only block when necessary (usually when told by the
539 user). 543 user).
540 544
541 The instrument to do that is called a "condition variable", so called 545 The tool to do that is called a "condition variable", so called because
542 because they represent a condition that must become true. 546 they represent a condition that must become true.
543 547
544 Now is probably a good time to look at the examples further below. 548 Now is probably a good time to look at the examples further below.
545 549
546 Condition variables can be created by calling the "AnyEvent->condvar" 550 Condition variables can be created by calling the "AnyEvent->condvar"
547 method, usually without arguments. The only argument pair allowed is 551 method, usually without arguments. The only argument pair allowed is
… …
552 After creation, the condition variable is "false" until it becomes 556 After creation, the condition variable is "false" until it becomes
553 "true" by calling the "send" method (or calling the condition variable 557 "true" by calling the "send" method (or calling the condition variable
554 as if it were a callback, read about the caveats in the description for 558 as if it were a callback, read about the caveats in the description for
555 the "->send" method). 559 the "->send" method).
556 560
557 Condition variables are similar to callbacks, except that you can 561 Since condition variables are the most complex part of the AnyEvent API,
558 optionally wait for them. They can also be called merge points - points 562 here are some different mental models of what they are - pick the ones
559 in time where multiple outstanding events have been processed. And yet 563 you can connect to:
560 another way to call them is transactions - each condition variable can 564
561 be used to represent a transaction, which finishes at some point and 565 * Condition variables are like callbacks - you can call them (and pass
562 delivers a result. And yet some people know them as "futures" - a 566 them instead of callbacks). Unlike callbacks however, you can also
563 promise to compute/deliver something that you can wait for. 567 wait for them to be called.
568
569 * Condition variables are signals - one side can emit or send them,
570 the other side can wait for them, or install a handler that is
571 called when the signal fires.
572
573 * Condition variables are like "Merge Points" - points in your program
574 where you merge multiple independent results/control flows into one.
575
576 * Condition variables represent a transaction - functions that start
577 some kind of transaction can return them, leaving the caller the
578 choice between waiting in a blocking fashion, or setting a callback.
579
580 * Condition variables represent future values, or promises to deliver
581 some result, long before the result is available.
564 582
565 Condition variables are very useful to signal that something has 583 Condition variables are very useful to signal that something has
566 finished, for example, if you write a module that does asynchronous http 584 finished, for example, if you write a module that does asynchronous http
567 requests, then a condition variable would be the ideal candidate to 585 requests, then a condition variable would be the ideal candidate to
568 signal the availability of results. The user can either act when the 586 signal the availability of results. The user can either act when the
… …
581 599
582 Condition variables are represented by hash refs in perl, and the keys 600 Condition variables are represented by hash refs in perl, and the keys
583 used by AnyEvent itself are all named "_ae_XXX" to make subclassing easy 601 used by AnyEvent itself are all named "_ae_XXX" to make subclassing easy
584 (it is often useful to build your own transaction class on top of 602 (it is often useful to build your own transaction class on top of
585 AnyEvent). To subclass, use "AnyEvent::CondVar" as base class and call 603 AnyEvent). To subclass, use "AnyEvent::CondVar" as base class and call
586 it's "new" method in your own "new" method. 604 its "new" method in your own "new" method.
587 605
588 There are two "sides" to a condition variable - the "producer side" 606 There are two "sides" to a condition variable - the "producer side"
589 which eventually calls "-> send", and the "consumer side", which waits 607 which eventually calls "-> send", and the "consumer side", which waits
590 for the send to occur. 608 for the send to occur.
591 609
592 Example: wait for a timer. 610 Example: wait for a timer.
593 611
594 # wait till the result is ready 612 # condition: "wait till the timer is fired"
595 my $result_ready = AnyEvent->condvar; 613 my $timer_fired = AnyEvent->condvar;
596 614
597 # do something such as adding a timer 615 # create the timer - we could wait for, say
598 # or socket watcher the calls $result_ready->send 616 # a handle becomign ready, or even an
599 # when the "result" is ready. 617 # AnyEvent::HTTP request to finish, but
600 # in this case, we simply use a timer: 618 # in this case, we simply use a timer:
601 my $w = AnyEvent->timer ( 619 my $w = AnyEvent->timer (
602 after => 1, 620 after => 1,
603 cb => sub { $result_ready->send }, 621 cb => sub { $timer_fired->send },
604 ); 622 );
605 623
606 # this "blocks" (while handling events) till the callback 624 # this "blocks" (while handling events) till the callback
607 # calls ->send 625 # calls ->send
608 $result_ready->recv; 626 $timer_fired->recv;
609 627
610 Example: wait for a timer, but take advantage of the fact that condition 628 Example: wait for a timer, but take advantage of the fact that condition
611 variables are also callable directly. 629 variables are also callable directly.
612 630
613 my $done = AnyEvent->condvar; 631 my $done = AnyEvent->condvar;
… …
651 Condition variables are overloaded so one can call them directly (as 669 Condition variables are overloaded so one can call them directly (as
652 if they were a code reference). Calling them directly is the same as 670 if they were a code reference). Calling them directly is the same as
653 calling "send". 671 calling "send".
654 672
655 $cv->croak ($error) 673 $cv->croak ($error)
656 Similar to send, but causes all call's to "->recv" to invoke 674 Similar to send, but causes all calls to "->recv" to invoke
657 "Carp::croak" with the given error message/object/scalar. 675 "Carp::croak" with the given error message/object/scalar.
658 676
659 This can be used to signal any errors to the condition variable 677 This can be used to signal any errors to the condition variable
660 user/consumer. Doing it this way instead of calling "croak" directly 678 user/consumer. Doing it this way instead of calling "croak" directly
661 delays the error detetcion, but has the overwhelmign advantage that 679 delays the error detection, but has the overwhelming advantage that
662 it diagnoses the error at the place where the result is expected, 680 it diagnoses the error at the place where the result is expected,
663 and not deep in some event clalback without connection to the actual 681 and not deep in some event callback with no connection to the actual
664 code causing the problem. 682 code causing the problem.
665 683
666 $cv->begin ([group callback]) 684 $cv->begin ([group callback])
667 $cv->end 685 $cv->end
668 These two methods can be used to combine many transactions/events 686 These two methods can be used to combine many transactions/events
… …
705 there is one call to "begin", so the condvar waits for all calls to 723 there is one call to "begin", so the condvar waits for all calls to
706 "end" before sending. 724 "end" before sending.
707 725
708 The ping example mentioned above is slightly more complicated, as 726 The ping example mentioned above is slightly more complicated, as
709 the there are results to be passwd back, and the number of tasks 727 the there are results to be passwd back, and the number of tasks
710 that are begung can potentially be zero: 728 that are begun can potentially be zero:
711 729
712 my $cv = AnyEvent->condvar; 730 my $cv = AnyEvent->condvar;
713 731
714 my %result; 732 my %result;
715 $cv->begin (sub { shift->send (\%result) }); 733 $cv->begin (sub { shift->send (\%result) });
… …
736 callback to be called once the counter reaches 0, and second, it 754 callback to be called once the counter reaches 0, and second, it
737 ensures that "send" is called even when "no" hosts are being pinged 755 ensures that "send" is called even when "no" hosts are being pinged
738 (the loop doesn't execute once). 756 (the loop doesn't execute once).
739 757
740 This is the general pattern when you "fan out" into multiple (but 758 This is the general pattern when you "fan out" into multiple (but
741 potentially none) subrequests: use an outer "begin"/"end" pair to 759 potentially zero) subrequests: use an outer "begin"/"end" pair to
742 set the callback and ensure "end" is called at least once, and then, 760 set the callback and ensure "end" is called at least once, and then,
743 for each subrequest you start, call "begin" and for each subrequest 761 for each subrequest you start, call "begin" and for each subrequest
744 you finish, call "end". 762 you finish, call "end".
745 763
746 METHODS FOR CONSUMERS 764 METHODS FOR CONSUMERS
747 These methods should only be used by the consuming side, i.e. the code 765 These methods should only be used by the consuming side, i.e. the code
748 awaits the condition. 766 awaits the condition.
749 767
750 $cv->recv 768 $cv->recv
751 Wait (blocking if necessary) until the "->send" or "->croak" methods 769 Wait (blocking if necessary) until the "->send" or "->croak" methods
752 have been called on c<$cv>, while servicing other watchers normally. 770 have been called on $cv, while servicing other watchers normally.
753 771
754 You can only wait once on a condition - additional calls are valid 772 You can only wait once on a condition - additional calls are valid
755 but will return immediately. 773 but will return immediately.
756 774
757 If an error condition has been set by calling "->croak", then this 775 If an error condition has been set by calling "->croak", then this
… …
774 example, by coupling condition variables with some kind of request 792 example, by coupling condition variables with some kind of request
775 results and supporting callbacks so the caller knows that getting 793 results and supporting callbacks so the caller knows that getting
776 the result will not block, while still supporting blocking waits if 794 the result will not block, while still supporting blocking waits if
777 the caller so desires). 795 the caller so desires).
778 796
779 You can ensure that "-recv" never blocks by setting a callback and 797 You can ensure that "->recv" never blocks by setting a callback and
780 only calling "->recv" from within that callback (or at a later 798 only calling "->recv" from within that callback (or at a later
781 time). This will work even when the event loop does not support 799 time). This will work even when the event loop does not support
782 blocking waits otherwise. 800 blocking waits otherwise.
783 801
784 $bool = $cv->ready 802 $bool = $cv->ready
… …
787 805
788 $cb = $cv->cb ($cb->($cv)) 806 $cb = $cv->cb ($cb->($cv))
789 This is a mutator function that returns the callback set and 807 This is a mutator function that returns the callback set and
790 optionally replaces it before doing so. 808 optionally replaces it before doing so.
791 809
792 The callback will be called when the condition becomes (or already 810 The callback will be called when the condition becomes "true", i.e.
793 was) "true", i.e. when "send" or "croak" are called (or were 811 when "send" or "croak" are called, with the only argument being the
794 called), with the only argument being the condition variable itself. 812 condition variable itself. If the condition is already true, the
795 Calling "recv" inside the callback or at any later time is 813 callback is called immediately when it is set. Calling "recv" inside
796 guaranteed not to block. 814 the callback or at any later time is guaranteed not to block.
797 815
798SUPPORTED EVENT LOOPS/BACKENDS 816SUPPORTED EVENT LOOPS/BACKENDS
799 The available backend classes are (every class has its own manpage): 817 The available backend classes are (every class has its own manpage):
800 818
801 Backends that are autoprobed when no other event loop can be found. 819 Backends that are autoprobed when no other event loop can be found.
… …
806 824
807 AnyEvent::Impl::EV based on EV (interface to libev, best choice). 825 AnyEvent::Impl::EV based on EV (interface to libev, best choice).
808 AnyEvent::Impl::Perl pure-perl implementation, fast and portable. 826 AnyEvent::Impl::Perl pure-perl implementation, fast and portable.
809 827
810 Backends that are transparently being picked up when they are used. 828 Backends that are transparently being picked up when they are used.
811 These will be used when they are currently loaded when the first 829 These will be used if they are already loaded when the first watcher
812 watcher is created, in which case it is assumed that the application 830 is created, in which case it is assumed that the application is
813 is using them. This means that AnyEvent will automatically pick the 831 using them. This means that AnyEvent will automatically pick the
814 right backend when the main program loads an event module before 832 right backend when the main program loads an event module before
815 anything starts to create watchers. Nothing special needs to be done 833 anything starts to create watchers. Nothing special needs to be done
816 by the main program. 834 by the main program.
817 835
818 AnyEvent::Impl::Event based on Event, very stable, few glitches. 836 AnyEvent::Impl::Event based on Event, very stable, few glitches.
… …
832 850
833 Support for IO::Async can only be partial, as it is too broken and 851 Support for IO::Async can only be partial, as it is too broken and
834 architecturally limited to even support the AnyEvent API. It also is 852 architecturally limited to even support the AnyEvent API. It also is
835 the only event loop that needs the loop to be set explicitly, so it 853 the only event loop that needs the loop to be set explicitly, so it
836 can only be used by a main program knowing about AnyEvent. See 854 can only be used by a main program knowing about AnyEvent. See
837 AnyEvent::Impl::Async for the gory details. 855 AnyEvent::Impl::IOAsync for the gory details.
838 856
839 AnyEvent::Impl::IOAsync based on IO::Async, cannot be autoprobed. 857 AnyEvent::Impl::IOAsync based on IO::Async, cannot be autoprobed.
840 858
841 Event loops that are indirectly supported via other backends. 859 Event loops that are indirectly supported via other backends.
842 Some event loops can be supported via other modules: 860 Some event loops can be supported via other modules:
… …
863 Contains "undef" until the first watcher is being created, before 881 Contains "undef" until the first watcher is being created, before
864 the backend has been autodetected. 882 the backend has been autodetected.
865 883
866 Afterwards it contains the event model that is being used, which is 884 Afterwards it contains the event model that is being used, which is
867 the name of the Perl class implementing the model. This class is 885 the name of the Perl class implementing the model. This class is
868 usually one of the "AnyEvent::Impl:xxx" modules, but can be any 886 usually one of the "AnyEvent::Impl::xxx" modules, but can be any
869 other class in the case AnyEvent has been extended at runtime (e.g. 887 other class in the case AnyEvent has been extended at runtime (e.g.
870 in *rxvt-unicode* it will be "urxvt::anyevent"). 888 in *rxvt-unicode* it will be "urxvt::anyevent").
871 889
872 AnyEvent::detect 890 AnyEvent::detect
873 Returns $AnyEvent::MODEL, forcing autodetection of the event model 891 Returns $AnyEvent::MODEL, forcing autodetection of the event model
874 if necessary. You should only call this function right before you 892 if necessary. You should only call this function right before you
875 would have created an AnyEvent watcher anyway, that is, as late as 893 would have created an AnyEvent watcher anyway, that is, as late as
876 possible at runtime, and not e.g. while initialising of your module. 894 possible at runtime, and not e.g. during initialisation of your
895 module.
877 896
878 If you need to do some initialisation before AnyEvent watchers are 897 If you need to do some initialisation before AnyEvent watchers are
879 created, use "post_detect". 898 created, use "post_detect".
880 899
881 $guard = AnyEvent::post_detect { BLOCK } 900 $guard = AnyEvent::post_detect { BLOCK }
882 Arranges for the code block to be executed as soon as the event 901 Arranges for the code block to be executed as soon as the event
883 model is autodetected (or immediately if this has already happened). 902 model is autodetected (or immediately if that has already happened).
884 903
885 The block will be executed *after* the actual backend has been 904 The block will be executed *after* the actual backend has been
886 detected ($AnyEvent::MODEL is set), but *before* any watchers have 905 detected ($AnyEvent::MODEL is set), but *before* any watchers have
887 been created, so it is possible to e.g. patch @AnyEvent::ISA or do 906 been created, so it is possible to e.g. patch @AnyEvent::ISA or do
888 other initialisations - see the sources of AnyEvent::Strict or 907 other initialisations - see the sources of AnyEvent::Strict or
… …
897 object that automatically removes the callback again when it is 916 object that automatically removes the callback again when it is
898 destroyed (or "undef" when the hook was immediately executed). See 917 destroyed (or "undef" when the hook was immediately executed). See
899 AnyEvent::AIO for a case where this is useful. 918 AnyEvent::AIO for a case where this is useful.
900 919
901 Example: Create a watcher for the IO::AIO module and store it in 920 Example: Create a watcher for the IO::AIO module and store it in
902 $WATCHER. Only do so after the event loop is initialised, though. 921 $WATCHER, but do so only do so after the event loop is initialised.
903 922
904 our WATCHER; 923 our WATCHER;
905 924
906 my $guard = AnyEvent::post_detect { 925 my $guard = AnyEvent::post_detect {
907 $WATCHER = AnyEvent->io (fh => IO::AIO::poll_fileno, poll => 'r', cb => \&IO::AIO::poll_cb); 926 $WATCHER = AnyEvent->io (fh => IO::AIO::poll_fileno, poll => 'r', cb => \&IO::AIO::poll_cb);
… …
914 933
915 $WATCHER ||= $guard; 934 $WATCHER ||= $guard;
916 935
917 @AnyEvent::post_detect 936 @AnyEvent::post_detect
918 If there are any code references in this array (you can "push" to it 937 If there are any code references in this array (you can "push" to it
919 before or after loading AnyEvent), then they will called directly 938 before or after loading AnyEvent), then they will be called directly
920 after the event loop has been chosen. 939 after the event loop has been chosen.
921 940
922 You should check $AnyEvent::MODEL before adding to this array, 941 You should check $AnyEvent::MODEL before adding to this array,
923 though: if it is defined then the event loop has already been 942 though: if it is defined then the event loop has already been
924 detected, and the array will be ignored. 943 detected, and the array will be ignored.
… …
959 stall the whole program, and the whole point of using events is to stay 978 stall the whole program, and the whole point of using events is to stay
960 interactive. 979 interactive.
961 980
962 It is fine, however, to call "->recv" when the user of your module 981 It is fine, however, to call "->recv" when the user of your module
963 requests it (i.e. if you create a http request object ad have a method 982 requests it (i.e. if you create a http request object ad have a method
964 called "results" that returns the results, it should call "->recv" 983 called "results" that returns the results, it may call "->recv" freely,
965 freely, as the user of your module knows what she is doing. always). 984 as the user of your module knows what she is doing. Always).
966 985
967WHAT TO DO IN THE MAIN PROGRAM 986WHAT TO DO IN THE MAIN PROGRAM
968 There will always be a single main program - the only place that should 987 There will always be a single main program - the only place that should
969 dictate which event model to use. 988 dictate which event model to use.
970 989
971 If it doesn't care, it can just "use AnyEvent" and use it itself, or not 990 If the program is not event-based, it need not do anything special, even
972 do anything special (it does not need to be event-based) and let 991 when it depends on a module that uses an AnyEvent. If the program itself
973 AnyEvent decide which implementation to chose if some module relies on 992 uses AnyEvent, but does not care which event loop is used, all it needs
974 it. 993 to do is "use AnyEvent". In either case, AnyEvent will choose the best
994 available loop implementation.
975 995
976 If the main program relies on a specific event model - for example, in 996 If the main program relies on a specific event model - for example, in
977 Gtk2 programs you have to rely on the Glib module - you should load the 997 Gtk2 programs you have to rely on the Glib module - you should load the
978 event module before loading AnyEvent or any module that uses it: 998 event module before loading AnyEvent or any module that uses it:
979 generally speaking, you should load it as early as possible. The reason 999 generally speaking, you should load it as early as possible. The reason
980 is that modules might create watchers when they are loaded, and AnyEvent 1000 is that modules might create watchers when they are loaded, and AnyEvent
981 will decide on the event model to use as soon as it creates watchers, 1001 will decide on the event model to use as soon as it creates watchers,
982 and it might chose the wrong one unless you load the correct one 1002 and it might choose the wrong one unless you load the correct one
983 yourself. 1003 yourself.
984 1004
985 You can chose to use a pure-perl implementation by loading the 1005 You can chose to use a pure-perl implementation by loading the
986 "AnyEvent::Impl::Perl" module, which gives you similar behaviour 1006 "AnyEvent::Impl::Perl" module, which gives you similar behaviour
987 everywhere, but letting AnyEvent chose the model is generally better. 1007 everywhere, but letting AnyEvent chose the model is generally better.
… …
1004 1024
1005OTHER MODULES 1025OTHER MODULES
1006 The following is a non-exhaustive list of additional modules that use 1026 The following is a non-exhaustive list of additional modules that use
1007 AnyEvent as a client and can therefore be mixed easily with other 1027 AnyEvent as a client and can therefore be mixed easily with other
1008 AnyEvent modules and other event loops in the same program. Some of the 1028 AnyEvent modules and other event loops in the same program. Some of the
1009 modules come with AnyEvent, most are available via CPAN. 1029 modules come as part of AnyEvent, the others are available via CPAN.
1010 1030
1011 AnyEvent::Util 1031 AnyEvent::Util
1012 Contains various utility functions that replace often-used but 1032 Contains various utility functions that replace often-used blocking
1013 blocking functions such as "inet_aton" by event-/callback-based 1033 functions such as "inet_aton" with event/callback-based versions.
1014 versions.
1015 1034
1016 AnyEvent::Socket 1035 AnyEvent::Socket
1017 Provides various utility functions for (internet protocol) sockets, 1036 Provides various utility functions for (internet protocol) sockets,
1018 addresses and name resolution. Also functions to create non-blocking 1037 addresses and name resolution. Also functions to create non-blocking
1019 tcp connections or tcp servers, with IPv6 and SRV record support and 1038 tcp connections or tcp servers, with IPv6 and SRV record support and
1020 more. 1039 more.
1021 1040
1022 AnyEvent::Handle 1041 AnyEvent::Handle
1023 Provide read and write buffers, manages watchers for reads and 1042 Provide read and write buffers, manages watchers for reads and
1024 writes, supports raw and formatted I/O, I/O queued and fully 1043 writes, supports raw and formatted I/O, I/O queued and fully
1025 transparent and non-blocking SSL/TLS (via AnyEvent::TLS. 1044 transparent and non-blocking SSL/TLS (via AnyEvent::TLS).
1026 1045
1027 AnyEvent::DNS 1046 AnyEvent::DNS
1028 Provides rich asynchronous DNS resolver capabilities. 1047 Provides rich asynchronous DNS resolver capabilities.
1029 1048
1049 AnyEvent::HTTP, AnyEvent::IRC, AnyEvent::XMPP, AnyEvent::GPSD,
1050 AnyEvent::IGS, AnyEvent::FCP
1051 Implement event-based interfaces to the protocols of the same name
1052 (for the curious, IGS is the International Go Server and FCP is the
1053 Freenet Client Protocol).
1054
1055 AnyEvent::Handle::UDP
1056 Here be danger!
1057
1058 As Pauli would put it, "Not only is it not right, it's not even
1059 wrong!" - there are so many things wrong with AnyEvent::Handle::UDP,
1060 most notably its use of a stream-based API with a protocol that
1061 isn't streamable, that the only way to improve it is to delete it.
1062
1063 It features data corruption (but typically only under load) and
1064 general confusion. On top, the author is not only clueless about UDP
1065 but also fact-resistant - some gems of his understanding: "connect
1066 doesn't work with UDP", "UDP packets are not IP packets", "UDP only
1067 has datagrams, not packets", "I don't need to implement proper error
1068 checking as UDP doesn't support error checking" and so on - he
1069 doesn't even understand what's wrong with his module when it is
1070 explained to him.
1071
1030 AnyEvent::HTTP 1072 AnyEvent::DBI
1031 A simple-to-use HTTP library that is capable of making a lot of 1073 Executes DBI requests asynchronously in a proxy process for you,
1032 concurrent HTTP requests. 1074 notifying you in an event-based way when the operation is finished.
1075
1076 AnyEvent::AIO
1077 Truly asynchronous (as opposed to non-blocking) I/O, should be in
1078 the toolbox of every event programmer. AnyEvent::AIO transparently
1079 fuses IO::AIO and AnyEvent together, giving AnyEvent access to
1080 event-based file I/O, and much more.
1033 1081
1034 AnyEvent::HTTPD 1082 AnyEvent::HTTPD
1035 Provides a simple web application server framework. 1083 A simple embedded webserver.
1036 1084
1037 AnyEvent::FastPing 1085 AnyEvent::FastPing
1038 The fastest ping in the west. 1086 The fastest ping in the west.
1039
1040 AnyEvent::DBI
1041 Executes DBI requests asynchronously in a proxy process.
1042
1043 AnyEvent::AIO
1044 Truly asynchronous I/O, should be in the toolbox of every event
1045 programmer. AnyEvent::AIO transparently fuses IO::AIO and AnyEvent
1046 together.
1047
1048 AnyEvent::BDB
1049 Truly asynchronous Berkeley DB access. AnyEvent::BDB transparently
1050 fuses BDB and AnyEvent together.
1051
1052 AnyEvent::GPSD
1053 A non-blocking interface to gpsd, a daemon delivering GPS
1054 information.
1055
1056 AnyEvent::IRC
1057 AnyEvent based IRC client module family (replacing the older
1058 Net::IRC3).
1059
1060 AnyEvent::XMPP
1061 AnyEvent based XMPP (Jabber protocol) module family (replacing the
1062 older Net::XMPP2>.
1063
1064 AnyEvent::IGS
1065 A non-blocking interface to the Internet Go Server protocol (used by
1066 App::IGS).
1067
1068 Net::FCP
1069 AnyEvent-based implementation of the Freenet Client Protocol,
1070 birthplace of AnyEvent.
1071
1072 Event::ExecFlow
1073 High level API for event-based execution flow control.
1074 1087
1075 Coro 1088 Coro
1076 Has special support for AnyEvent via Coro::AnyEvent. 1089 Has special support for AnyEvent via Coro::AnyEvent.
1077 1090
1078SIMPLIFIED AE API 1091SIMPLIFIED AE API
1079 Starting with version 5.0, AnyEvent officially supports a second, much 1092 Starting with version 5.0, AnyEvent officially supports a second, much
1080 simpler, API that is designed to reduce the calling, typing and memory 1093 simpler, API that is designed to reduce the calling, typing and memory
1081 overhead. 1094 overhead by using function call syntax and a fixed number of parameters.
1082 1095
1083 See the AE manpage for details. 1096 See the AE manpage for details.
1084 1097
1085ERROR AND EXCEPTION HANDLING 1098ERROR AND EXCEPTION HANDLING
1086 In general, AnyEvent does not do any error handling - it relies on the 1099 In general, AnyEvent does not do any error handling - it relies on the
… …
1129 thoroughly check the arguments passed to most method calls. If it 1142 thoroughly check the arguments passed to most method calls. If it
1130 finds any problems, it will croak. 1143 finds any problems, it will croak.
1131 1144
1132 In other words, enables "strict" mode. 1145 In other words, enables "strict" mode.
1133 1146
1134 Unlike "use strict" (or it's modern cousin, "use common::sense", it 1147 Unlike "use strict" (or its modern cousin, "use common::sense", it
1135 is definitely recommended to keep it off in production. Keeping 1148 is definitely recommended to keep it off in production. Keeping
1136 "PERL_ANYEVENT_STRICT=1" in your environment while developing 1149 "PERL_ANYEVENT_STRICT=1" in your environment while developing
1137 programs can be very useful, however. 1150 programs can be very useful, however.
1138 1151
1139 "PERL_ANYEVENT_MODEL" 1152 "PERL_ANYEVENT_MODEL"
… …
1351 1364
1352 The actual code goes further and collects all errors ("die"s, 1365 The actual code goes further and collects all errors ("die"s,
1353 exceptions) that occurred during request processing. The "result" method 1366 exceptions) that occurred during request processing. The "result" method
1354 detects whether an exception as thrown (it is stored inside the $txn 1367 detects whether an exception as thrown (it is stored inside the $txn
1355 object) and just throws the exception, which means connection errors and 1368 object) and just throws the exception, which means connection errors and
1356 other problems get reported tot he code that tries to use the result, 1369 other problems get reported to the code that tries to use the result,
1357 not in a random callback. 1370 not in a random callback.
1358 1371
1359 All of this enables the following usage styles: 1372 All of this enables the following usage styles:
1360 1373
1361 1. Blocking: 1374 1. Blocking:
… …
1735 1748
1736 Feel free to install your own handler, or reset it to defaults. 1749 Feel free to install your own handler, or reset it to defaults.
1737 1750
1738RECOMMENDED/OPTIONAL MODULES 1751RECOMMENDED/OPTIONAL MODULES
1739 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and 1752 One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and
1740 it's built-in modules) are required to use it. 1753 its built-in modules) are required to use it.
1741 1754
1742 That does not mean that AnyEvent won't take advantage of some additional 1755 That does not mean that AnyEvent won't take advantage of some additional
1743 modules if they are installed. 1756 modules if they are installed.
1744 1757
1745 This section explains which additional modules will be used, and how 1758 This section explains which additional modules will be used, and how
… …
1774 clock is available, can take avdantage of advanced kernel interfaces 1787 clock is available, can take avdantage of advanced kernel interfaces
1775 such as "epoll" and "kqueue", and is the fastest backend *by far*. 1788 such as "epoll" and "kqueue", and is the fastest backend *by far*.
1776 You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and 1789 You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and
1777 Glib::EV). 1790 Glib::EV).
1778 1791
1792 If you only use backends that rely on another event loop (e.g.
1793 "Tk"), then this module will do nothing for you.
1794
1779 Guard 1795 Guard
1780 The guard module, when used, will be used to implement 1796 The guard module, when used, will be used to implement
1781 "AnyEvent::Util::guard". This speeds up guards considerably (and 1797 "AnyEvent::Util::guard". This speeds up guards considerably (and
1782 uses a lot less memory), but otherwise doesn't affect guard 1798 uses a lot less memory), but otherwise doesn't affect guard
1783 operation much. It is purely used for performance. 1799 operation much. It is purely used for performance.
1784 1800
1785 JSON and JSON::XS 1801 JSON and JSON::XS
1786 One of these modules is required when you want to read or write JSON 1802 One of these modules is required when you want to read or write JSON
1787 data via AnyEvent::Handle. It is also written in pure-perl, but can 1803 data via AnyEvent::Handle. JSON is also written in pure-perl, but
1788 take advantage of the ultra-high-speed JSON::XS module when it is 1804 can take advantage of the ultra-high-speed JSON::XS module when it
1789 installed. 1805 is installed.
1790
1791 In fact, AnyEvent::Handle will use JSON::XS by default if it is
1792 installed.
1793 1806
1794 Net::SSLeay 1807 Net::SSLeay
1795 Implementing TLS/SSL in Perl is certainly interesting, but not very 1808 Implementing TLS/SSL in Perl is certainly interesting, but not very
1796 worthwhile: If this module is installed, then AnyEvent::Handle (with 1809 worthwhile: If this module is installed, then AnyEvent::Handle (with
1797 the help of AnyEvent::TLS), gains the ability to do TLS/SSL. 1810 the help of AnyEvent::TLS), gains the ability to do TLS/SSL.
1798 1811
1799 Time::HiRes 1812 Time::HiRes
1800 This module is part of perl since release 5.008. It will be used 1813 This module is part of perl since release 5.008. It will be used
1801 when the chosen event library does not come with a timing source on 1814 when the chosen event library does not come with a timing source of
1802 it's own. The pure-perl event loop (AnyEvent::Impl::Perl) will 1815 its own. The pure-perl event loop (AnyEvent::Impl::Perl) will
1803 additionally use it to try to use a monotonic clock for timing 1816 additionally use it to try to use a monotonic clock for timing
1804 stability. 1817 stability.
1805 1818
1806FORK 1819FORK
1807 Most event libraries are not fork-safe. The ones who are usually are 1820 Most event libraries are not fork-safe. The ones who are usually are
… …
1860 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other 1873 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other
1861 annoying memleaks, such as leaking on "map" and "grep" but it is usually 1874 annoying memleaks, such as leaking on "map" and "grep" but it is usually
1862 not as pronounced). 1875 not as pronounced).
1863 1876
1864SEE ALSO 1877SEE ALSO
1878 Tutorial/Introduction: AnyEvent::Intro.
1879
1880 FAQ: AnyEvent::FAQ.
1881
1865 Utility functions: AnyEvent::Util. 1882 Utility functions: AnyEvent::Util.
1866 1883
1867 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk, 1884 Event modules: EV, EV::Glib, Glib::EV, Event, Glib::Event, Glib, Tk,
1868 Event::Lib, Qt, POE. 1885 Event::Lib, Qt, POE.
1869 1886
… …
1875 Non-blocking file handles, sockets, TCP clients and servers: 1892 Non-blocking file handles, sockets, TCP clients and servers:
1876 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS. 1893 AnyEvent::Handle, AnyEvent::Socket, AnyEvent::TLS.
1877 1894
1878 Asynchronous DNS: AnyEvent::DNS. 1895 Asynchronous DNS: AnyEvent::DNS.
1879 1896
1880 Coroutine support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event, 1897 Thread support: Coro, Coro::AnyEvent, Coro::EV, Coro::Event.
1881 1898
1882 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::XMPP, 1899 Nontrivial usage examples: AnyEvent::GPSD, AnyEvent::IRC,
1883 AnyEvent::HTTP. 1900 AnyEvent::HTTP.
1884 1901
1885AUTHOR 1902AUTHOR
1886 Marc Lehmann <schmorp@schmorp.de> 1903 Marc Lehmann <schmorp@schmorp.de>
1887 http://home.schmorp.de/ 1904 http://home.schmorp.de/

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines