| 1 | =head1 NAME |
1 | =head1 NAME |
| 2 | |
2 | |
| 3 | AnyEvent - provide framework for multiple event loops |
3 | AnyEvent - events independent of event loop implementation |
| 4 | |
4 | |
| 5 | EV, Event, Glib, Tk, Perl, Event::Lib, Qt and POE are various supported |
5 | EV, Event, Glib, Tk, Perl, Event::Lib, Qt and POE are various supported |
| 6 | event loops. |
6 | event loops. |
| 7 | |
7 | |
| 8 | =head1 SYNOPSIS |
8 | =head1 SYNOPSIS |
| … | |
… | |
| 40 | =head1 INTRODUCTION/TUTORIAL |
40 | =head1 INTRODUCTION/TUTORIAL |
| 41 | |
41 | |
| 42 | This manpage is mainly a reference manual. If you are interested |
42 | This manpage is mainly a reference manual. If you are interested |
| 43 | in a tutorial or some gentle introduction, have a look at the |
43 | in a tutorial or some gentle introduction, have a look at the |
| 44 | L<AnyEvent::Intro> manpage. |
44 | L<AnyEvent::Intro> manpage. |
|
|
45 | |
|
|
46 | =head1 SUPPORT |
|
|
47 | |
|
|
48 | There is a mailinglist for discussing all things AnyEvent, and an IRC |
|
|
49 | channel, too. |
|
|
50 | |
|
|
51 | See the AnyEvent project page at the B<Schmorpforge Ta-Sa Software |
|
|
52 | Respository>, at L<http://anyevent.schmorp.de>, for more info. |
| 45 | |
53 | |
| 46 | =head1 WHY YOU SHOULD USE THIS MODULE (OR NOT) |
54 | =head1 WHY YOU SHOULD USE THIS MODULE (OR NOT) |
| 47 | |
55 | |
| 48 | Glib, POE, IO::Async, Event... CPAN offers event models by the dozen |
56 | Glib, POE, IO::Async, Event... CPAN offers event models by the dozen |
| 49 | nowadays. So what is different about AnyEvent? |
57 | nowadays. So what is different about AnyEvent? |
| … | |
… | |
| 368 | |
376 | |
| 369 | This watcher might use C<%SIG> (depending on the event loop used), |
377 | This watcher might use C<%SIG> (depending on the event loop used), |
| 370 | so programs overwriting those signals directly will likely not work |
378 | so programs overwriting those signals directly will likely not work |
| 371 | correctly. |
379 | correctly. |
| 372 | |
380 | |
|
|
381 | Example: exit on SIGINT |
|
|
382 | |
|
|
383 | my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 }); |
|
|
384 | |
|
|
385 | =head3 Signal Races, Delays and Workarounds |
|
|
386 | |
| 373 | Also note that many event loops (e.g. Glib, Tk, Qt, IO::Async) do not |
387 | Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching |
| 374 | support attaching callbacks to signals, which is a pity, as you cannot do |
388 | callbacks to signals in a generic way, which is a pity, as you cannot do |
| 375 | race-free signal handling in perl. AnyEvent will try to do it's best, but |
389 | race-free signal handling in perl. AnyEvent will try to do it's best, but |
| 376 | in some cases, signals will be delayed. The maximum time a signal might |
390 | in some cases, signals will be delayed. The maximum time a signal might |
| 377 | be delayed is specified in C<$AnyEvent::MAX_SIGNAL_LATENCY> (default: 10 |
391 | be delayed is specified in C<$AnyEvent::MAX_SIGNAL_LATENCY> (default: 10 |
| 378 | seconds). This variable can be changed only before the first signal |
392 | seconds). This variable can be changed only before the first signal |
| 379 | watcher is created, and should be left alone otherwise. Higher values |
393 | watcher is created, and should be left alone otherwise. Higher values |
| 380 | will cause fewer spurious wake-ups, which is better for power and CPU |
394 | will cause fewer spurious wake-ups, which is better for power and CPU |
| 381 | saving. All these problems can be avoided by installing the optional |
395 | saving. All these problems can be avoided by installing the optional |
| 382 | L<Async::Interrupt> module. |
396 | L<Async::Interrupt> module. This will not work with inherently broken |
| 383 | |
397 | event loops such as L<Event> or L<Event::Lib> (and not with L<POE> |
| 384 | Example: exit on SIGINT |
398 | currently, as POE does it's own workaround with one-second latency). With |
| 385 | |
399 | those, you just have to suffer the delays. |
| 386 | my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 }); |
|
|
| 387 | |
400 | |
| 388 | =head2 CHILD PROCESS WATCHERS |
401 | =head2 CHILD PROCESS WATCHERS |
| 389 | |
402 | |
| 390 | You can also watch on a child process exit and catch its exit status. |
403 | You can also watch on a child process exit and catch its exit status. |
| 391 | |
404 | |
| … | |
… | |
| 2270 | |
2283 | |
| 2271 | This slightly arcane module is used to implement fast signal handling: To |
2284 | This slightly arcane module is used to implement fast signal handling: To |
| 2272 | my knowledge, there is no way to do completely race-free and quick |
2285 | my knowledge, there is no way to do completely race-free and quick |
| 2273 | signal handling in pure perl. To ensure that signals still get |
2286 | signal handling in pure perl. To ensure that signals still get |
| 2274 | delivered, AnyEvent will start an interval timer to wake up perl (and |
2287 | delivered, AnyEvent will start an interval timer to wake up perl (and |
| 2275 | catch the signals) with soemd elay (default is 10 seconds, look for |
2288 | catch the signals) with some delay (default is 10 seconds, look for |
| 2276 | C<$AnyEvent::MAX_SIGNAL_LATENCY>). |
2289 | C<$AnyEvent::MAX_SIGNAL_LATENCY>). |
| 2277 | |
2290 | |
| 2278 | If this module is available, then it will be used to implement signal |
2291 | If this module is available, then it will be used to implement signal |
| 2279 | catching, which means that signals will not be delayed, and the event loop |
2292 | catching, which means that signals will not be delayed, and the event loop |
| 2280 | will not be interrupted regularly, which is more efficient (And good for |
2293 | will not be interrupted regularly, which is more efficient (And good for |
| 2281 | battery life on laptops). |
2294 | battery life on laptops). |
| 2282 | |
2295 | |
| 2283 | This affects not just the pure-perl event loop, but also other event loops |
2296 | This affects not just the pure-perl event loop, but also other event loops |
| 2284 | that have no signal handling on their own (e.g. Glib, Tk, Qt). |
2297 | that have no signal handling on their own (e.g. Glib, Tk, Qt). |
|
|
2298 | |
|
|
2299 | Some event loops (POE, Event, Event::Lib) offer signal watchers natively, |
|
|
2300 | and either employ their own workarounds (POE) or use AnyEvent's workaround |
|
|
2301 | (using C<$AnyEvent::MAX_SIGNAL_LATENCY>). Installing L<Async::Interrupt> |
|
|
2302 | does nothing for those backends. |
| 2285 | |
2303 | |
| 2286 | =item L<EV> |
2304 | =item L<EV> |
| 2287 | |
2305 | |
| 2288 | This module isn't really "optional", as it is simply one of the backend |
2306 | This module isn't really "optional", as it is simply one of the backend |
| 2289 | event loops that AnyEvent can use. However, it is simply the best event |
2307 | event loops that AnyEvent can use. However, it is simply the best event |
| … | |
… | |
| 2303 | |
2321 | |
| 2304 | =item L<JSON> and L<JSON::XS> |
2322 | =item L<JSON> and L<JSON::XS> |
| 2305 | |
2323 | |
| 2306 | This module is required when you want to read or write JSON data via |
2324 | This module is required when you want to read or write JSON data via |
| 2307 | L<AnyEvent::Handle>. It is also written in pure-perl, but can take |
2325 | L<AnyEvent::Handle>. It is also written in pure-perl, but can take |
| 2308 | advantage of the ulta-high-speed L<JSON::XS> module when it is installed. |
2326 | advantage of the ultra-high-speed L<JSON::XS> module when it is installed. |
| 2309 | |
2327 | |
| 2310 | In fact, L<AnyEvent::Handle> will use L<JSON::XS> by default if it is |
2328 | In fact, L<AnyEvent::Handle> will use L<JSON::XS> by default if it is |
| 2311 | installed. |
2329 | installed. |
| 2312 | |
2330 | |
| 2313 | =item L<Net::SSLeay> |
2331 | =item L<Net::SSLeay> |
