AnyEvent
view release on metacpan or search on metacpan
resolve and are not in hosts (analyzed by sten).
7.02 Tue Aug 14 04:27:58 CEST 2012
- AnyEvent::Util::run_cmd could block indefinitely (analyzed and test
program by Yorhel).
- verified that AnyEvent::Socket follows RFC5952.
- try to parse "ADDR#PORT" in addition to "ADDR PORT".
7.01 Sun May 13 01:03:17 CEST 2012
- fail with EPROTO in AnyEvent::Handle wqhen TLS is requested but
not available, instead of throwing an exception.
- use File::Spec to get the tmpdir in t/*, to avoid needless
failures on (most, not mine :) windows boxes.
- new handle read types: tls_detect and tls_autostart.
7.0 Fri Apr 13 06:33:30 CEST 2012
- child watchers are broken in POE 1.352 (also many earlier
versions) and there seems to be no way to work around it, as POE
itself is inherently racy. Document this regression and add a delay
in t/68_poe_03_child.t for the time being.
- new module AnyEvent::IO, that is a frontend to either a pure-perl
- the default logging level was not properly documented in a variety of
places, this has hopefully been rectified.
- updated uts46data.pl for unicode 6.1.0.
- made log messages generated by AnyEvent submodules not
include the package name anymore, as it will be logged
by default already.
- upgrade to the trick used by common-sense 3.5 to work
around extra warning torture/breakage under perl 5.15.x.
- log messages by anyevent are now ucfirst, are usually full
sentences and do no longer include the package name.
- the storable read type would sometimes throw an exception instead
of causing EBADMSG (analyzed by Maxime Soulé).
- work around a bug in openssl 1.0.1 which enforces a minimum rsa
keysize (reported by Paul Howarth).
- documented Rocco fabricating statements about AnyEvent and me.
6.14 Tue Jan 31 20:00:24 CET 2012
- AnyEvent::Impl::Tk was broken due to a mysterious "die" inside,
probably an editing mistake (reported by Darin McBride).
6.13 Thu Jan 12 07:27:01 CET 2012
5.23 Sun Dec 20 23:48:00 CET 2009
- support IDNs in resolve_sockaddr, and therefore in tcp_connect.
- implement punycode_encode/decode, idn_nameprep,
idn_to_ascii and idn_to_unicode operations in AnyEvent::Util.
- provide $AE::VERSION.
- removed traces of "no strict 'refs'".
5.22 Sat Dec 5 03:51:13 CET 2009
- downgrade-or-fail in AnyEvent::Handle::push_write, to
diagnose encoding failures earlier and more succinctly.
(this works around bugs in perl, throwing away encoding info
when passing scalar data to extensions).
- add more examples to AnyEvent::Socket manpage.
- upgrade internal warning set to the same as common::sense 2.03.
- use pack "n/a*" for pre-5.8.9 perl compatibility in AnyEvent::DNS
(John Beppu).
- AnyEvent::Socket::inet_aton now properly supports ipv6, as documented.
- add google public dns servers to fallback server set and make sure
we load-balance properly between the three sets. also add all
fallback dns servers, not just a random one, to each dns config.
5.202 Wed Oct 14 22:35:44 CEST 2009
- AnyEvent::DNS would unexpectedly clobber $_ under windows
(analysed by Matthias Waldorf).
- AnyEvent::Handle::run_cmd can now pass the PID of the
newly-created process, which is much less useful than it might
sound (based on patch by Yann Kerherve).
5.201 Tue Sep 29 12:09:25 CEST 2009
- AnyEvent:Handle::on_starttls/on_stoptls methods were broken
(reported by Torsten Foertsch).
- common::sense 2.0 could cause tcp_server to throw an exception
(analysed by elmex).
5.2 Mon Sep 14 07:04:49 CEST 2009
- INCOMPATIBLE CHANGE: do no longer support register_read_type
and register_write_type in AnyEvent::Handle, instead support
package names (the facility was mostly abused).
- implement "packagename-as-read/write type" support in
AnyEvent::Handle.
- AnyEvent::Handle: new options "keepalive" and "oobinline".
- oobinline set by default to avoid security issues.
- added simple io watcher test to testsuite, using a
portable_socketpair.
- tried to improve the stability of the Event::Lib backend,
YMMV.
4.8 Mon Jul 6 23:45:16 CEST 2009
- AnyEvent::DNS did not properly follow CNAME records with
uppercase targets.
- AnyEvent::DNS would errornously return AAAA records
with v4 mapped addresses (a faulty record) as ipv4 addresses,
causing AnyEvent::Socket to throw an exception.
- added new module AnyEvent::TLS for easier SSL/TLS context
creation, with many options including hostname verification,
secure default configuration, lots of documentation and,
predefined diffie-hellman keys for perfect forward security
and much more. get it while it's still fresh!
- use AnyEvent::TLS in AnyEvent::Handle for context management.
- load AnyEvent::Handle only on demand in AnyEvent::DNS,
so AnyEvent::Socket users have smaller memory footprint
in the common case.
- add AnyEvent::Handle->push_shutdown method.
See the AE manpage for details.
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
AnyEvent supports a number of environment variables that tune the
runtime behaviour. They are usually evaluated when AnyEvent is loaded,
initialised, or a submodule that uses them is loaded. Many of them also
cause AnyEvent to load additional modules - for example,
"PERL_ANYEVENT_DEBUG_WRAP" causes the AnyEvent::Debug module to be
loaded.
If you want to do more than just set the global logging level you
should have a look at "PERL_ANYEVENT_LOG", which allows much more
complex specifications.
When set to 0 ("off"), then no messages whatsoever will be logged
with everything else at defaults.
When set to 5 or higher ("warn"), AnyEvent warns about unexpected
conditions, such as not being able to load the event model specified
by "PERL_ANYEVENT_MODEL", or a guard callback throwing an exception
- this is the minimum recommended level for use during development.
When set to 7 or higher (info), AnyEvent reports which event model
it chooses.
When set to 8 or higher (debug), then AnyEvent will report extra
information on which optional modules it loads and how it implements
certain features.
"PERL_ANYEVENT_LOG"
The "result" method, finally, just waits for the finished signal (if the
request was already finished, it doesn't wait, of course, and returns
the data:
$txn->{finished}->recv;
return $txn->{result};
The actual code goes further and collects all errors ("die"s,
exceptions) that occurred during request processing. The "result" method
detects whether an exception as thrown (it is stored inside the $txn
object) and just throws the exception, which means connection errors and
other problems get reported to the code that tries to use the result,
not in a random callback.
All of this enables the following usage styles:
1. Blocking:
my $data = $fcp->client_get ($url);
2. Blocking, but running in parallel:
lib/AnyEvent.pm view on Meta::CPAN
*wait = \&recv;
=head1 ERROR AND EXCEPTION HANDLING
In general, AnyEvent does not do any error handling - it relies on the
caller to do that if required. The L<AnyEvent::Strict> module (see also
the C<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 C<< condvar->recv >>), the L<Event> and L<EV> modules call C<<
$Event/EV::DIED->() >>, L<Glib> uses C<< install_exception_handler >> and
so on.
=head1 ENVIRONMENT VARIABLES
AnyEvent supports a number of environment variables that tune the
runtime behaviour. They are usually evaluated when AnyEvent is
loaded, initialised, or a submodule that uses them is loaded. Many of
them also cause AnyEvent to load additional modules - for example,
lib/AnyEvent.pm view on Meta::CPAN
If you want to do more than just set the global logging level
you should have a look at C<PERL_ANYEVENT_LOG>, which allows much more
complex specifications.
When set to C<0> (C<off>), then no messages whatsoever will be logged with
everything else at defaults.
When set to C<5> or higher (C<warn>), AnyEvent warns about unexpected
conditions, such as not being able to load the event model specified by
C<PERL_ANYEVENT_MODEL>, or a guard callback throwing an exception - this
is the minimum recommended level for use during development.
When set to C<7> or higher (info), AnyEvent reports which event model it
chooses.
When set to C<8> or higher (debug), then AnyEvent will report extra
information on which optional modules it loads and how it implements
certain features.
=item C<PERL_ANYEVENT_LOG>
lib/AnyEvent.pm view on Meta::CPAN
The C<result> method, finally, just waits for the finished signal (if the
request was already finished, it doesn't wait, of course, and returns the
data:
$txn->{finished}->recv;
return $txn->{result};
The actual code goes further and collects all errors (C<die>s, exceptions)
that occurred during request processing. The C<result> method detects
whether an exception as thrown (it is stored inside the $txn object)
and just throws the exception, which means connection errors and other
problems get reported to the code that tries to use the result, not in a
random callback.
All of this enables the following usage styles:
1. Blocking:
my $data = $fcp->client_get ($url);
2. Blocking, but running in parallel:
lib/AnyEvent/FAQ.pod view on Meta::CPAN
EV::loop;
=head2 Why is my C<tcp_connect> callback never called?
Tricky: C<tcp_connect> (and a few other functions in L<AnyEvent::Socket>)
is critically sensitive to the caller context.
In void context, it will just do its thing and eventually call the
callback. In any other context, however, it will return a special "guard"
object - when it is destroyed (e.g. when you don't store it but throw it
away), tcp_connect will no longer try to connect or call any callbacks.
Often this happens when the C<tcp_connect> call is at the end of a function:
sub do_connect {
tcp_connect "www.example.com", 80, sub {
... lengthy code
};
}
lib/AnyEvent/FAQ.pod view on Meta::CPAN
on the other side will then look at the queue.
AnyEvent to GUI communications can also use a L<Thread::Queue>, but to
wake up the GUI thread, it would instead use C<< Win32::GUI::PostMessage
$WINDOW, 1030, 0, "" >>, and the GUI thread would listen for these
messages by using C<< $WINDOW->Hook (1030 (), sub { ... }) >>.
=head2 My callback dies and...
It must not - part of the contract betwene AnyEvent and user code is that
callbacks do not throw exceptions (and don't do even more evil things,
such as using C<last> outside a loop :). If your callback might die
sometimes, you need to use C<eval>.
If you want to track down such a case and you can reproduce it, you can
enable wrapping (by calling C<< L<AnyEvent::Debug>::wrap >> or by setting
C<PERL_ANYEVENT_DEBUG_WRAP=1> before starting your program). This will
wrap every callback into an eval and will report any exception complete
with a backtrace and some information about which watcher died, where it
was created and so on.
lib/AnyEvent/Impl/POE.pm view on Meta::CPAN
condition variables), POE will print an ugly, unsuppressible, message at
program exit:
Sessions were started, but POE::Kernel's run() method was never...
The message is correct, the question is why POE prints it in the first
place in a correct program (this is not a singular case though).
AnyEvent consequently patches the POE kernel so it thinks it already
ran. Other workarounds, even the one cited in the POE documentation
itself, have serious side effects, such as throwing away events.
The author of POE verified that this is indeed true, and has no plans to
change this.
POE has other weird messages, and sometimes weird behaviour, for example,
it doesn't support overloaded code references as callbacks for no apparent
reason.
=item One POE session per Event
lib/AnyEvent/Util.pm view on Meta::CPAN
This function creates a special object that, when destroyed, will execute
the code block.
This is often handy in continuation-passing style code to clean up some
resource regardless of where you break out of a process.
The L<Guard> module will be used to implement this function, if it is
available. Otherwise a pure-perl implementation is used.
While the code is allowed to throw exceptions in unusual conditions, it is
not defined whether this exception will be reported (at the moment, the
Guard module and AnyEvent's pure-perl implementation both try to report
the error and continue).
You can call one method on the returned object:
=item $guard->cancel
This simply causes the code block not to be invoked: it "cancels" the
guard.
( run in 0.442 second using v1.01-cache-2.11-cpan-496ff517765 )