--- AnyEvent/README 2008/05/24 17:58:33 1.22 +++ AnyEvent/README 2008/10/03 07:19:23 1.32 @@ -1,4 +1,4 @@ -=> NAME +NAME AnyEvent - provide framework for multiple event loops EV, Event, Glib, Tk, Perl, Event::Lib, Qt, POE - various supported event @@ -7,17 +7,31 @@ SYNOPSIS use AnyEvent; - my $w = AnyEvent->io (fh => $fh, poll => "r|w", cb => sub { - ... - }); + my $w = AnyEvent->io (fh => $fh, poll => "r|w", cb => sub { ... }); + + my $w = AnyEvent->timer (after => $seconds, cb => sub { ... }); + my $w = AnyEvent->timer (after => $seconds, interval => $seconds, cb => ... + + print AnyEvent->now; # prints current event loop time + print AnyEvent->time; # think Time::HiRes::time or simply CORE::time. + + my $w = AnyEvent->signal (signal => "TERM", cb => sub { ... }); - my $w = AnyEvent->timer (after => $seconds, cb => sub { + my $w = AnyEvent->child (pid => $pid, cb => sub { + my ($pid, $status) = @_; ... }); my $w = AnyEvent->condvar; # stores whether a condition was flagged $w->send; # wake up current and all future recv's $w->recv; # enters "main loop" till $condvar gets ->send + # use a condvar in callback mode: + $w->cb (sub { $_[0]->recv }); + +INTRODUCTION/TUTORIAL + This manpage is mainly a reference manual. If you are interested in a + tutorial or some gentle introduction, have a look at the AnyEvent::Intro + manpage. WHY YOU SHOULD USE THIS MODULE (OR NOT) Glib, POE, IO::Async, Event... CPAN offers event models by the dozen @@ -27,11 +41,12 @@ policy* and AnyEvent is *small and efficient*. First and foremost, *AnyEvent is not an event model* itself, it only - interfaces to whatever event model the main program happens to use in a + interfaces to whatever event model the main program happens to use, in a pragmatic way. For event models and certain classes of immortals alike, the statement "there can only be one" is a bitter reality: In general, only one event loop can be active at the same time in a process. - AnyEvent helps hiding the differences between those event loops. + AnyEvent cannot change this, but it can hide the differences between + those event loops. The goal of AnyEvent is to offer module authors the ability to do event programming (waiting for I/O or timer events) without subscribing to a @@ -42,18 +57,18 @@ For modules like POE or IO::Async (which is a total misnomer as it is actually doing all I/O *synchronously*...), using them in your module is like joining a cult: After you joined, you are dependent on them and you - cannot use anything else, as it is simply incompatible to everything - that isn't itself. What's worse, all the potential users of your module + cannot use anything else, as they are simply incompatible to everything + that isn't them. What's worse, all the potential users of your module are *also* forced to use the same event loop you use. AnyEvent is different: AnyEvent + POE works fine. AnyEvent + Glib works fine. AnyEvent + Tk works fine etc. etc. but none of these work together - with the rest: POE + IO::Async? no go. Tk + Event? no go. Again: if your + with the rest: POE + IO::Async? No go. Tk + Event? No go. Again: if your module uses one of those, every user of your module has to use it, too. But if your module uses AnyEvent, it works transparently with all event - models it supports (including stuff like POE and IO::Async, as long as - those use one of the supported event loops. It is trivial to add new - event loops to AnyEvent, too, so it is future-proof). + models it supports (including stuff like IO::Async, as long as those use + one of the supported event loops. It is trivial to add new event loops + to AnyEvent, too, so it is future-proof). In addition to being free of having to use *the one and only true event model*, AnyEvent also is free of bloat and policy: with POE or similar @@ -62,7 +77,13 @@ only offering the functionality that is necessary, in as thin as a wrapper as technically possible. - Of course, if you want lots of policy (this can arguably be somewhat + Of course, AnyEvent comes with a big (and fully optional!) toolbox of + useful functionality, such as an asynchronous DNS resolver, 100% + non-blocking connects (even with TLS/SSL, IPv6 and on broken platforms + such as Windows) and lots of real-world knowledge and workarounds for + platform bugs and differences. + + Now, if you *do want* lots of policy (this can arguably be somewhat useful) and you want to force your users to use the one and only event model, you should *not* use this module. @@ -101,7 +122,7 @@ The pure-perl implementation of AnyEvent is called "AnyEvent::Impl::Perl". Like other event modules you can load it - explicitly. + explicitly and enjoy the high availability of that event loop :) WATCHERS AnyEvent has the central concept of a *watcher*, which is an object that @@ -124,10 +145,10 @@ An any way to achieve that is this pattern: - my $w; $w = AnyEvent->type (arg => value ..., cb => sub { - # you can use $w here, for example to undef it - undef $w; - }); + my $w; $w = AnyEvent->type (arg => value ..., cb => sub { + # you can use $w here, for example to undef it + undef $w; + }); Note that "my $w; $w =" combination. This is necessary because in Perl, my variables are only visible after the statement in which they are @@ -137,7 +158,8 @@ You can create an I/O watcher by calling the "AnyEvent->io" method with the following mandatory key-value pairs as arguments: - "fh" the Perl *file handle* (*not* file descriptor) to watch for events. + "fh" the Perl *file handle* (*not* file descriptor) to watch for events + (AnyEvent might or might not keep a reference to this file handle). "poll" must be a string that is either "r" or "w", which creates a watcher waiting for "r"eadable or "w"ritable events, respectively. "cb" is the callback to invoke each time the file handle becomes ready. @@ -154,9 +176,9 @@ always use non-blocking calls when reading/writing from/to your file handles. - Example: + Example: wait for readability of STDIN, then read a line and disable the + watcher. - # wait for readability of STDIN, then read a line and disable the watcher my $w; $w = AnyEvent->io (fh => \*STDIN, poll => 'r', cb => sub { chomp (my $input = ); warn "read: $input\n"; @@ -175,13 +197,18 @@ presence is undefined and you cannot rely on them. Portable AnyEvent callbacks cannot use arguments passed to time watcher callbacks. - The timer callback will be invoked at most once: if you want a repeating - timer you have to create a new watcher (this is a limitation by both Tk - and Glib). + The callback will normally be invoked once only. If you specify another + parameter, "interval", as a strictly positive number (> 0), then the + callback will be invoked regularly at that interval (in fractional + seconds) after the first invocation. If "interval" is specified with a + false value, then it is treated as if it were missing. + + The callback will be rescheduled before invoking the callback, but no + attempt is done to avoid timer drift in most backends, so the interval + is only approximate. - Example: + Example: fire an event after 7.7 seconds. - # fire an event after 7.7 seconds my $w = AnyEvent->timer (after => 7.7, cb => sub { warn "timeout\n"; }); @@ -189,19 +216,12 @@ # to cancel the timer: undef $w; - Example 2: - - # fire an event after 0.5 seconds, then roughly every second - my $w; + Example 2: fire an event after 0.5 seconds, then roughly every second. - my $cb = sub { - # cancel the old timer while creating a new one - $w = AnyEvent->timer (after => 1, cb => $cb); + my $w = AnyEvent->timer (after => 0.5, interval => 1, cb => sub { + warn "timeout\n"; }; - # start the "loop" by creating the first watcher - $w = AnyEvent->timer (after => 0.5, cb => $cb); - TIMING ISSUES There are two ways to handle timers: based on real time (relative, "fire in 10 seconds") and based on wallclock time (absolute, "fire at 12 @@ -222,10 +242,72 @@ AnyEvent always prefers relative timers, if available, matching the AnyEvent API. + AnyEvent has two additional methods that return the "current time": + + AnyEvent->time + This returns the "current wallclock time" as a fractional number of + seconds since the Epoch (the same thing as "time" or + "Time::HiRes::time" return, and the result is guaranteed to be + compatible with those). + + It progresses independently of any event loop processing, i.e. each + call will check the system clock, which usually gets updated + frequently. + + AnyEvent->now + This also returns the "current wallclock time", but unlike "time", + above, this value might change only once per event loop iteration, + depending on the event loop (most return the same time as "time", + above). This is the time that AnyEvent's timers get scheduled + against. + + *In almost all cases (in all cases if you don't care), this is the + function to call when you want to know the current time.* + + This function is also often faster then "AnyEvent->time", and thus + the preferred method if you want some timestamp (for example, + AnyEvent::Handle uses this to update it's activity timeouts). + + The rest of this section is only of relevance if you try to be very + exact with your timing, you can skip it without bad conscience. + + For a practical example of when these times differ, consider + Event::Lib and EV and the following set-up: + + The event loop is running and has just invoked one of your callback + at time=500 (assume no other callbacks delay processing). In your + callback, you wait a second by executing "sleep 1" (blocking the + process for a second) and then (at time=501) you create a relative + timer that fires after three seconds. + + With Event::Lib, "AnyEvent->time" and "AnyEvent->now" will both + return 501, because that is the current time, and the timer will be + scheduled to fire at time=504 (501 + 3). + + With EV, "AnyEvent->time" returns 501 (as that is the current time), + but "AnyEvent->now" returns 500, as that is the time the last event + processing phase started. With EV, your timer gets scheduled to run + at time=503 (500 + 3). + + In one sense, Event::Lib is more exact, as it uses the current time + regardless of any delays introduced by event processing. However, + most callbacks do not expect large delays in processing, so this + causes a higher drift (and a lot more system calls to get the + current time). + + In another sense, EV is more exact, as your timer will be scheduled + at the same time, regardless of how long event processing actually + took. + + In either case, if you care (and in most cases, you don't), then you + can get whatever behaviour you want with any event loop, by taking + the difference between "AnyEvent->time" and "AnyEvent->now" into + account. + SIGNAL WATCHERS You can watch for signals using a signal watcher, "signal" is the signal - *name* without any "SIG" prefix, "cb" is the Perl callback to be invoked - whenever a signal occurs. + *name* in uppercase and without any "SIG" prefix, "cb" is the Perl + callback to be invoked whenever a signal occurs. Although the callback might get passed parameters, their value and presence is undefined and you cannot rely on them. Portable AnyEvent @@ -250,11 +332,18 @@ You can also watch on a child process exit and catch its exit status. The child process is specified by the "pid" argument (if set to 0, it - watches for any child process exit). The watcher will trigger as often - as status change for the child are received. This works by installing a - signal handler for "SIGCHLD". The callback will be called with the pid - and exit status (as returned by waitpid), so unlike other watcher types, - you *can* rely on child watcher callback arguments. + watches for any child process exit). The watcher will triggered only + when the child process has finished and an exit status is available, not + on any trace events (stopped/continued). + + The callback will be called with the pid and exit status (as returned by + waitpid), so unlike other watcher types, you *can* rely on child watcher + callback arguments. + + This watcher type works by installing a signal handler for "SIGCHLD", + and since it cannot be shared, nothing else should use SIGCHLD or reap + random child processes (waiting for specific child processes, e.g. + inside "system", is just fine). There is a slight catch to child watchers, however: you usually start them *after* the child process was created, and this means the process @@ -271,21 +360,21 @@ Example: fork a process and wait for it - my $done = AnyEvent->condvar; - - my $pid = fork or exit 5; - - my $w = AnyEvent->child ( - pid => $pid, - cb => sub { - my ($pid, $status) = @_; - warn "pid $pid exited with status $status"; - $done->send; - }, - ); - - # do something else, then wait for process exit - $done->recv; + my $done = AnyEvent->condvar; + + my $pid = fork or exit 5; + + my $w = AnyEvent->child ( + pid => $pid, + cb => sub { + my ($pid, $status) = @_; + warn "pid $pid exited with status $status"; + $done->send; + }, + ); + + # do something else, then wait for process exit + $done->recv; CONDITION VARIABLES If you are familiar with some event loops you will know that all of them @@ -300,12 +389,15 @@ Condition variables can be created by calling the "AnyEvent->condvar" method, usually without arguments. The only argument pair allowed is + "cb", which specifies a callback to be called when the condition - variable becomes true. + variable becomes true, with the condition variable as the first argument + (but not the results). After creation, the condition variable is "false" until it becomes "true" by calling the "send" method (or calling the condition variable - as if it were a callback). + as if it were a callback, read about the caveats in the description for + the "->send" method). Condition variables are similar to callbacks, except that you can optionally wait for them. They can also be called merge points - points @@ -366,6 +458,23 @@ my $delay = AnyEvent->timer (after => 5, cb => $done); $done->recv; + Example: Imagine an API that returns a condvar and doesn't support + callbacks. This is how you make a synchronous call, for example from the + main program: + + use AnyEvent::CouchDB; + + ... + + my @info = $couchdb->info->recv; + + And this is how you would just ste a callback to be called whenever the + results are available: + + $couchdb->info->cb (sub { + my @info = $_[0]->recv; + }); + METHODS FOR PRODUCERS These methods should only be used by the producing side, i.e. the code/module that eventually sends the signal. Note that it is also the @@ -385,7 +494,12 @@ Condition variables are overloaded so one can call them directly (as a code reference). Calling them directly is the same as calling - "send". + "send". Note, however, that many C-based event loops do not handle + overloading, so as tempting as it may be, passing a condition + variable instead of a callback does not work. Both the pure perl and + EV loops support overloading, however, as well as all functions that + use perl to invoke a callback (as in AnyEvent::Socket and + AnyEvent::DNS for example). $cv->croak ($error) Similar to send, but causes all call's to "->recv" to invoke @@ -490,13 +604,14 @@ Returns true when the condition is "true", i.e. whether "send" or "croak" have been called. - $cb = $cv->cb ([new callback]) + $cb = $cv->cb ($cb->($cv)) This is a mutator function that returns the callback set and optionally replaces it before doing so. The callback will be called when the condition becomes "true", i.e. - when "send" or "croak" are called. Calling "recv" inside the - callback or at any later time is guaranteed not to block. + when "send" or "croak" are called, with the only argument being the + condition variable itself. Calling "recv" inside the callback or at + any later time is guaranteed not to block. GLOBAL VARIABLES AND FUNCTIONS $AnyEvent::MODEL @@ -580,8 +695,8 @@ AnyEvent decide which implementation to chose if some module relies on it. - If the main program relies on a specific event model. For example, in - Gtk2 programs you have to rely on the Glib module. You should load the + If the main program relies on a specific event model - for example, in + Gtk2 programs you have to rely on the Glib module - you should load the event module before loading AnyEvent or any module that uses it: generally speaking, you should load it as early as possible. The reason is that modules might create watchers when they are loaded, and AnyEvent @@ -589,9 +704,25 @@ and it might chose the wrong one unless you load the correct one yourself. - You can chose to use a rather inefficient pure-perl implementation by - loading the "AnyEvent::Impl::Perl" module, which gives you similar - behaviour everywhere, but letting AnyEvent chose is generally better. + You can chose to use a pure-perl implementation by loading the + "AnyEvent::Impl::Perl" module, which gives you similar behaviour + everywhere, but letting AnyEvent chose the model is generally better. + + MAINLOOP EMULATION + Sometimes (often for short test scripts, or even standalone programs who + only want to use AnyEvent), you do not want to run a specific event + loop. + + In that case, you can use a condition variable like this: + + AnyEvent->condvar->recv; + + This has the effect of entering the event loop and looping forever. + + Note that usually your program has some exit condition, in which case it + is better to use the "traditional" approach of storing a condition + variable somewhere, waiting for it, and sending it when the program + should exit cleanly. OTHER MODULES The following is a non-exhaustive list of additional modules that use @@ -604,27 +735,53 @@ blocking functions such as "inet_aton" by event-/callback-based versions. - AnyEvent::Handle - Provide read and write buffers and manages watchers for reads and - writes. - AnyEvent::Socket Provides various utility functions for (internet protocol) sockets, addresses and name resolution. Also functions to create non-blocking tcp connections or tcp servers, with IPv6 and SRV record support and more. - AnyEvent::HTTPD - Provides a simple web application server framework. + AnyEvent::Handle + Provide read and write buffers, manages watchers for reads and + writes, supports raw and formatted I/O, I/O queued and fully + transparent and non-blocking SSL/TLS. AnyEvent::DNS Provides rich asynchronous DNS resolver capabilities. + AnyEvent::HTTP + A simple-to-use HTTP library that is capable of making a lot of + concurrent HTTP requests. + + AnyEvent::HTTPD + Provides a simple web application server framework. + AnyEvent::FastPing The fastest ping in the west. - Net::IRC3 - AnyEvent based IRC client module family. + AnyEvent::DBI + Executes DBI requests asynchronously in a proxy process. + + AnyEvent::AIO + Truly asynchronous I/O, should be in the toolbox of every event + programmer. AnyEvent::AIO transparently fuses IO::AIO and AnyEvent + together. + + AnyEvent::BDB + Truly asynchronous Berkeley DB access. AnyEvent::BDB transparently + fuses BDB and AnyEvent together. + + AnyEvent::GPSD + A non-blocking interface to gpsd, a daemon delivering GPS + information. + + AnyEvent::IGS + A non-blocking interface to the Internet Go Server protocol (used by + App::IGS). + + AnyEvent::IRC + AnyEvent based IRC client module family (replacing the older + Net::IRC3). Net::XMPP2 AnyEvent based XMPP (Jabber protocol) module family. @@ -639,64 +796,29 @@ Coro Has special support for AnyEvent via Coro::AnyEvent. - AnyEvent::AIO, IO::AIO - Truly asynchronous I/O, should be in the toolbox of every event - programmer. AnyEvent::AIO transparently fuses IO::AIO and AnyEvent - together. - - AnyEvent::BDB, BDB - Truly asynchronous Berkeley DB access. AnyEvent::AIO transparently - fuses IO::AIO and AnyEvent together. - IO::Lambda The lambda approach to I/O - don't ask, look there. Can use AnyEvent. -SUPPLYING YOUR OWN EVENT MODEL INTERFACE - This is an advanced topic that you do not normally need to use AnyEvent - in a module. This section is only of use to event loop authors who want - to provide AnyEvent compatibility. - - If you need to support another event library which isn't directly - supported by AnyEvent, you can supply your own interface to it by - pushing, before the first watcher gets created, the package name of the - event module and the package name of the interface to use onto - @AnyEvent::REGISTRY. You can do that before and even without loading - AnyEvent, so it is reasonably cheap. - - Example: - - push @AnyEvent::REGISTRY, [urxvt => urxvt::anyevent::]; - - This tells AnyEvent to (literally) use the "urxvt::anyevent::" - package/class when it finds the "urxvt" package/module is already - loaded. - - When AnyEvent is loaded and asked to find a suitable event model, it - will first check for the presence of urxvt by trying to "use" the - "urxvt::anyevent" module. - - The class should provide implementations for all watcher types. See - AnyEvent::Impl::EV (source code), AnyEvent::Impl::Glib (Source code) and - so on for actual examples. Use "perldoc -m AnyEvent::Impl::Glib" to see - the sources. - - If you don't provide "signal" and "child" watchers than AnyEvent will - provide suitable (hopefully) replacements. - - The above example isn't fictitious, the *rxvt-unicode* (a.k.a. urxvt) - terminal emulator uses the above line as-is. An interface isn't included - in AnyEvent because it doesn't make sense outside the embedded - interpreter inside *rxvt-unicode*, and it is updated and maintained as - part of the *rxvt-unicode* distribution. - - *rxvt-unicode* also cheats a bit by not providing blocking access to - condition variables: code blocking while waiting for a condition will - "die". This still works with most modules/usages, and blocking calls - must not be done in an interactive application, so it makes sense. +ERROR AND EXCEPTION HANDLING + In general, AnyEvent does not do any error handling - it relies on the + caller to do that if required. The AnyEvent::Strict module (see also the + "PERL_ANYEVENT_STRICT" environment variable, below) provides strict + checking of all AnyEvent methods, however, which is highly useful during + development. + + As for exception handling (i.e. runtime errors and exceptions thrown + while executing a callback), this is not only highly event-loop + specific, but also not in any way wrapped by this module, as this is the + job of the main program. + + The pure perl event loop simply re-throws the exception (usually within + "condvar->recv"), the Event and EV modules call "$Event/EV::DIED->()", + Glib uses "install_exception_handler" and so on. ENVIRONMENT VARIABLES - The following environment variables are used by this module: + The following environment variables are used by this module or its + submodules: "PERL_ANYEVENT_VERBOSE" By default, AnyEvent will be completely silent except in fatal @@ -710,6 +832,19 @@ When set to 2 or higher, cause AnyEvent to report to STDERR which event model it chooses. + "PERL_ANYEVENT_STRICT" + AnyEvent does not do much argument checking by default, as thorough + argument checking is very costly. Setting this variable to a true + value will cause AnyEvent to load "AnyEvent::Strict" and then to + thoroughly check the arguments passed to most method calls. If it + finds any problems it will croak. + + In other words, enables "strict" mode. + + Unlike "use strict", it is definitely recommended ot keep it off in + production. Keeping "PERL_ANYEVENT_STRICT=1" in your environment + while developing programs can be very useful, however. + "PERL_ANYEVENT_MODEL" This can be used to specify the event model to be used by AnyEvent, before auto detection and -probing kicks in. It must be a string @@ -723,7 +858,7 @@ For example, to force the pure perl model (AnyEvent::Impl::Perl) you could start your program like this: - PERL_ANYEVENT_MODEL=Perl perl ... + PERL_ANYEVENT_MODEL=Perl perl ... "PERL_ANYEVENT_PROTOCOLS" Used by both AnyEvent::DNS and AnyEvent::Socket to determine @@ -756,6 +891,53 @@ Setting this variable to 1 will cause AnyEvent::DNS to announce EDNS0 in its DNS requests. + "PERL_ANYEVENT_MAX_FORKS" + The maximum number of child processes that + "AnyEvent::Util::fork_call" will create in parallel. + +SUPPLYING YOUR OWN EVENT MODEL INTERFACE + This is an advanced topic that you do not normally need to use AnyEvent + in a module. This section is only of use to event loop authors who want + to provide AnyEvent compatibility. + + If you need to support another event library which isn't directly + supported by AnyEvent, you can supply your own interface to it by + pushing, before the first watcher gets created, the package name of the + event module and the package name of the interface to use onto + @AnyEvent::REGISTRY. You can do that before and even without loading + AnyEvent, so it is reasonably cheap. + + Example: + + push @AnyEvent::REGISTRY, [urxvt => urxvt::anyevent::]; + + This tells AnyEvent to (literally) use the "urxvt::anyevent::" + package/class when it finds the "urxvt" package/module is already + loaded. + + When AnyEvent is loaded and asked to find a suitable event model, it + will first check for the presence of urxvt by trying to "use" the + "urxvt::anyevent" module. + + The class should provide implementations for all watcher types. See + AnyEvent::Impl::EV (source code), AnyEvent::Impl::Glib (Source code) and + so on for actual examples. Use "perldoc -m AnyEvent::Impl::Glib" to see + the sources. + + If you don't provide "signal" and "child" watchers than AnyEvent will + provide suitable (hopefully) replacements. + + The above example isn't fictitious, the *rxvt-unicode* (a.k.a. urxvt) + terminal emulator uses the above line as-is. An interface isn't included + in AnyEvent because it doesn't make sense outside the embedded + interpreter inside *rxvt-unicode*, and it is updated and maintained as + part of the *rxvt-unicode* distribution. + + *rxvt-unicode* also cheats a bit by not providing blocking access to + condition variables: code blocking while waiting for a condition will + "die". This still works with most modules/usages, and blocking calls + must not be done in an interactive application, so it makes sense. + EXAMPLE PROGRAM The following program uses an I/O watcher to read data from STDIN, a timer to display a message once per second, and a condition variable to @@ -1151,6 +1333,30 @@ * C-based event loops perform very well with small number of watchers, as the management overhead dominates. +SIGNALS + AnyEvent currently installs handlers for these signals: + + SIGCHLD + A handler for "SIGCHLD" is installed by AnyEvent's child watcher + emulation for event loops that do not support them natively. Also, + some event loops install a similar handler. + + SIGPIPE + A no-op handler is installed for "SIGPIPE" when $SIG{PIPE} is + "undef" when AnyEvent gets loaded. + + The rationale for this is that AnyEvent users usually do not really + depend on SIGPIPE delivery (which is purely an optimisation for + shell use, or badly-written programs), but "SIGPIPE" can cause + spurious and rare program exits as a lot of people do not expect + "SIGPIPE" when writing to some random socket. + + The rationale for installing a no-op handler as opposed to ignoring + it is that this way, the handler will be restored to defaults on + exec. + + Feel free to install your own handler, or reset it to defaults. + FORK Most event libraries are not fork-safe. The ones who are usually are because they rely on inefficient but fork-safe "select" or "poll" calls. @@ -1170,13 +1376,21 @@ You can make AnyEvent completely ignore this variable by deleting it before the first watcher gets created, e.g. with a "BEGIN" block: - BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} } - - use AnyEvent; + BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} } + + use AnyEvent; Similar considerations apply to $ENV{PERL_ANYEVENT_VERBOSE}, as that can be used to probe what backend is used and gain other information (which - is probably even less useful to an attacker than PERL_ANYEVENT_MODEL). + is probably even less useful to an attacker than PERL_ANYEVENT_MODEL), + and $ENV{PERL_ANYEGENT_STRICT}. + +BUGS + Perl 5.8 has numerous memleaks that sometimes hit this module and are + hard to work around. If you suffer from memleaks, first upgrade to Perl + 5.10 and check wether the leaks still show up. (Perl 5.10.0 has other + annoying mamleaks, such as leaking on "map" and "grep" but it is usually + not as pronounced). SEE ALSO Utility functions: AnyEvent::Util. @@ -1198,6 +1412,6 @@ Nontrivial usage examples: Net::FCP, Net::XMPP2, AnyEvent::DNS. AUTHOR - Marc Lehmann - http://home.schmorp.de/ + Marc Lehmann + http://home.schmorp.de/