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

Comparing AnyEvent/README (file contents):
Revision 1.52 by root, Mon Aug 10 01:17:38 2009 UTC vs.
Revision 1.56 by root, Thu Nov 19 01:55:57 2009 UTC

… …
353 then this "current" time will differ substantially from the real 353 then this "current" time will differ substantially from the real
354 time, which might affect timers and time-outs. 354 time, which might affect timers and time-outs.
355 355
356 When this is the case, you can call this method, which will update 356 When this is the case, you can call this method, which will update
357 the event loop's idea of "current time". 357 the event loop's idea of "current time".
358
359 A typical example would be a script in a web server (e.g.
360 "mod_perl") - when mod_perl executes the script, then the event loop
361 will have the wrong idea about the "current time" (being potentially
362 far in the past, when the script ran the last time). In that case
363 you should arrange a call to "AnyEvent->now_update" each time the
364 web server process wakes up again (e.g. at the start of your script,
365 or in a handler).
358 366
359 Note that updating the time *might* cause some events to be handled. 367 Note that updating the time *might* cause some events to be handled.
360 368
361 SIGNAL WATCHERS 369 SIGNAL WATCHERS
362 $w = AnyEvent->signal (signal => <uppercase_signal_name>, cb => <callback>); 370 $w = AnyEvent->signal (signal => <uppercase_signal_name>, cb => <callback>);
… …
576 after => 1, 584 after => 1,
577 cb => sub { $result_ready->send }, 585 cb => sub { $result_ready->send },
578 ); 586 );
579 587
580 # this "blocks" (while handling events) till the callback 588 # this "blocks" (while handling events) till the callback
581 # calls -<send 589 # calls ->send
582 $result_ready->recv; 590 $result_ready->recv;
583 591
584 Example: wait for a timer, but take advantage of the fact that condition 592 Example: wait for a timer, but take advantage of the fact that condition
585 variables are also callable directly. 593 variables are also callable directly.
586 594
… …
1228 warn "read: $input\n"; # output what has been read 1236 warn "read: $input\n"; # output what has been read
1229 $cv->send if $input =~ /^q/i; # quit program if /^q/i 1237 $cv->send if $input =~ /^q/i; # quit program if /^q/i
1230 }, 1238 },
1231 ); 1239 );
1232 1240
1233 my $time_watcher; # can only be used once
1234
1235 sub new_timer {
1236 $timer = AnyEvent->timer (after => 1, cb => sub { 1241 my $time_watcher = AnyEvent->timer (after => 1, interval => 1, cb => sub {
1237 warn "timeout\n"; # print 'timeout' about every second 1242 warn "timeout\n"; # print 'timeout' at most every second
1238 &new_timer; # and restart the time
1239 });
1240 } 1243 });
1241
1242 new_timer; # create first timer
1243 1244
1244 $cv->recv; # wait until user enters /^q/i 1245 $cv->recv; # wait until user enters /^q/i
1245 1246
1246REAL-WORLD EXAMPLE 1247REAL-WORLD EXAMPLE
1247 Consider the Net::FCP module. It features (among others) the following 1248 Consider the Net::FCP module. It features (among others) the following
… …
1665 As you can see, the AnyEvent + EV combination even beats the 1666 As you can see, the AnyEvent + EV combination even beats the
1666 hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl 1667 hand-optimised "raw sockets benchmark", while AnyEvent + its pure perl
1667 backend easily beats IO::Lambda and POE. 1668 backend easily beats IO::Lambda and POE.
1668 1669
1669 And even the 100% non-blocking version written using the high-level (and 1670 And even the 100% non-blocking version written using the high-level (and
1670 slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda by a 1671 slow :) AnyEvent::Handle abstraction beats both POE and IO::Lambda
1671 large margin, even though it does all of DNS, tcp-connect and socket I/O 1672 higher level ("unoptimised") abstractions by a large margin, even though
1672 in a non-blocking way. 1673 it does all of DNS, tcp-connect and socket I/O in a non-blocking way.
1673 1674
1674 The two AnyEvent benchmarks programs can be found as eg/ae0.pl and 1675 The two AnyEvent benchmarks programs can be found as eg/ae0.pl and
1675 eg/ae2.pl in the AnyEvent distribution, the remaining benchmarks are 1676 eg/ae2.pl in the AnyEvent distribution, the remaining benchmarks are
1676 part of the IO::lambda distribution and were used without any changes. 1677 part of the IO::Lambda distribution and were used without any changes.
1677 1678
1678SIGNALS 1679SIGNALS
1679 AnyEvent currently installs handlers for these signals: 1680 AnyEvent currently installs handlers for these signals:
1680 1681
1681 SIGCHLD 1682 SIGCHLD
… …
1749 "AnyEvent::Util::guard". This speeds up guards considerably (and 1750 "AnyEvent::Util::guard". This speeds up guards considerably (and
1750 uses a lot less memory), but otherwise doesn't affect guard 1751 uses a lot less memory), but otherwise doesn't affect guard
1751 operation much. It is purely used for performance. 1752 operation much. It is purely used for performance.
1752 1753
1753 JSON and JSON::XS 1754 JSON and JSON::XS
1754 This module is required when you want to read or write JSON data via 1755 One of these modules is required when you want to read or write JSON
1755 AnyEvent::Handle. It is also written in pure-perl, but can take 1756 data via AnyEvent::Handle. It is also written in pure-perl, but can
1756 advantage of the ultra-high-speed JSON::XS module when it is 1757 take advantage of the ultra-high-speed JSON::XS module when it is
1757 installed. 1758 installed.
1758 1759
1759 In fact, AnyEvent::Handle will use JSON::XS by default if it is 1760 In fact, AnyEvent::Handle will use JSON::XS by default if it is
1760 installed. 1761 installed.
1761 1762

Diff Legend

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