AnyEvent
view release on metacpan or search on metacpan
function will call "croak".
In list context, all parameters passed to "send" will be returned,
in scalar context only the first one will be returned.
Note that doing a blocking wait in a callback is not supported by
any event loop, that is, recursive invocation of a blocking "->recv"
is not allowed and the "recv" call will "croak" if such a condition
is detected. This requirement can be dropped by relying on
Coro::AnyEvent , which allows you to do a blocking "->recv" from any
thread that doesn't run the event loop itself. Coro::AnyEvent is
loaded automatically when Coro is used with AnyEvent, so code does
not need to do anything special to take advantage of that: any code
that would normally block your program because it calls "recv", be
executed in an "async" thread instead without blocking other
threads.
Not all event models support a blocking wait - some die in that case
(programs might want to do that to stay interactive), so *if you are
using this from a module, never require a blocking wait*. Instead,
let the caller decide whether the call will block or not (for
example, by coupling condition variables with some kind of request
results and supporting callbacks so the caller knows that getting
the result will not block, while still supporting blocking waits if
the caller so desires).
much more complicated: even for backends that *are* fork-aware or
fork-safe, their behaviour is not usually what you want: fork clones all
watchers, that means all timers, I/O watchers etc. are active in both
parent and child, which is almost never what you want. Using "exec" to
start worker children from some kind of manage prrocess is usually
preferred, because it is much easier and cleaner, at the expense of
having to have another binary.
In addition to logical problems with fork, there are also implementation
problems. For example, on POSIX systems, you cannot fork at all in Perl
code if a thread (I am talking of pthreads here) was ever created in the
process, and this is just the tip of the iceberg. In general, using fork
from Perl is difficult, and attempting to use fork without an exec to
implement some kind of parallel processing is almost certainly doomed.
To safely fork and exec, you should use a module such as Proc::FastSpawn
that let's you safely fork and exec new processes.
If you want to do multiprocessing using processes, you can look at the
AnyEvent::Fork module (and some related modules such as
AnyEvent::Fork::RPC, AnyEvent::Fork::Pool and AnyEvent::Fork::Remote).
constants.pl.PL view on Meta::CPAN
$oldstdout = select $fh;
print "# automatically generated from constants.pl.PL\n";
}
{
# from common::sense 3.74
use strict qw(vars subs);
no warnings;
use warnings qw(FATAL closed threads internal debugging pack malloc portable prototype
inplace io pipe unpack glob digit printf
layer reserved taint closure semicolon);
no warnings qw(exec newline unopened);
BEGIN {
print "sub AnyEvent::common_sense {\n";
printf " local \$^W;\n";
printf " \${^WARNING_BITS} ^= \${^WARNING_BITS} ^ \"%s\";\n",
join "", map "\\x$_", unpack "(H2)*", ${^WARNING_BITS};
# use strict, use utf8;
lib/AnyEvent.pm view on Meta::CPAN
If an error condition has been set by calling C<< ->croak >>, then this
function will call C<croak>.
In list context, all parameters passed to C<send> will be returned,
in scalar context only the first one will be returned.
Note that doing a blocking wait in a callback is not supported by any
event loop, that is, recursive invocation of a blocking C<< ->recv >> is
not allowed and the C<recv> call will C<croak> if such a condition is
detected. This requirement can be dropped by relying on L<Coro::AnyEvent>
, which allows you to do a blocking C<< ->recv >> from any thread
that doesn't run the event loop itself. L<Coro::AnyEvent> is loaded
automatically when L<Coro> is used with L<AnyEvent>, so code does not need
to do anything special to take advantage of that: any code that would
normally block your program because it calls C<recv>, be executed in an
C<async> thread instead without blocking other threads.
Not all event models support a blocking wait - some die in that case
(programs might want to do that to stay interactive), so I<if you are
using this from a module, never require a blocking wait>. Instead, let the
caller decide whether the call will block or not (for example, by coupling
condition variables with some kind of request results and supporting
callbacks so the caller knows that getting the result will not block,
while still supporting blocking waits if the caller so desires).
You can ensure that C<< ->recv >> never blocks by setting a callback and
lib/AnyEvent.pm view on Meta::CPAN
is much more complicated: even for backends that I<are> fork-aware or
fork-safe, their behaviour is not usually what you want: fork clones all
watchers, that means all timers, I/O watchers etc. are active in both
parent and child, which is almost never what you want. Using C<exec>
to start worker children from some kind of manage prrocess is usually
preferred, because it is much easier and cleaner, at the expense of having
to have another binary.
In addition to logical problems with fork, there are also implementation
problems. For example, on POSIX systems, you cannot fork at all in Perl
code if a thread (I am talking of pthreads here) was ever created in the
process, and this is just the tip of the iceberg. In general, using fork
from Perl is difficult, and attempting to use fork without an exec to
implement some kind of parallel processing is almost certainly doomed.
To safely fork and exec, you should use a module such as
L<Proc::FastSpawn> that let's you safely fork and exec new processes.
If you want to do multiprocessing using processes, you can
look at the L<AnyEvent::Fork> module (and some related modules
such as L<AnyEvent::Fork::RPC>, L<AnyEvent::Fork::Pool> and
lib/AnyEvent/FAQ.pod view on Meta::CPAN
big deal: as soon as your program actually implements I<something>, the
CPU usage will be normal.
=head2 Why does this FAQ not deal with L<AnyEvent::Handle> questions?
Because L<AnyEvent::Handle> has a NONFAQ on its own that already deals
with common issues.
=head2 How can I combine L<Win32::GUI> applications with AnyEvent?
Well, not in the same OS thread, that's for sure :) What you can do is
create another ithread (or fork) and run AnyEvent inside that thread, or
better yet, run all your GUI code in a second ithread.
For example, you could load L<Win32::GUI> and L<AnyEvent::Util>, then
create a portable socketpair for GUI->AnyEvent communication.
Then fork/create a new ithread, in there, create a Window and send the C<<
$WINDOW->{-Handle} >> to the AnyEvent ithread so it can C<PostMessage>.
GUI to AnyEvent communication could work by pushing some data into a
L<Thread::Queue> and writing a byte into the socket. The AnyEvent watcher
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
lib/AnyEvent/IO.pm view on Meta::CPAN
passes these bytes to C<$cb>. Otherwise the semantics are very much like
those of Perl's C<sysread>.
If less than C<$length> octets have been read, C<$data> will contain
only those bytes actually read. At EOF, C<$data> will be a zero-length
string. If an error occurs, then nothing is passed to the callback.
Obviously, multiple C<aio_read>'s or C<aio_write>'s at the same time on file
handles sharing the underlying open file description results in undefined
behaviour, due to sharing of the current file offset (and less obviously
so, because OS X is not thread safe and corrupts data when you try).
Example: read 128 octets from a file.
aio_read $fh, 128, sub {
my ($data) = @_
or return AE::log error "read from fh: $!";
if (length $data) {
print "read ", length $data, " octets.\n";
} else {
lib/AnyEvent/IO.pm view on Meta::CPAN
Tries to write the octets in C<$data> to the current position of C<$fh>
and passes the actual number of bytes written to the C<$cb>. Otherwise the
semantics are very much like those of Perl's C<syswrite>.
If less than C<length $data> octets have been written, C<$length> will
reflect that. If an error occurs, then nothing is passed to the callback.
Obviously, multiple C<aio_read>'s or C<aio_write>'s at the same time on file
handles sharing the underlying open file description results in undefined
behaviour, due to sharing of the current file offset (and less obviously
so, because OS X is not thread safe and corrupts data when you try).
=item aio_truncate $fh_or_path, $new_length, $cb->($success)
Calls C<truncate> on the path or perl file handle and passes a true value
to the callback on success.
Example: truncate F</etc/passwd> to zero length - this only works on
systems that support C<truncate>, should not be tried out for obvious
reasons and debian will probably open yte another security bug about this
example.
lib/AnyEvent/Impl/Irssi.pm view on Meta::CPAN
This I<should> have no negative effect, as AnyEvent will emit a pidwait
signal just like irssi itself would.
=item * Artificial timer delays.
Irssi artificially enforces timers to have at least a 10ms delay (by
croaking, even).
This means that some applications will be limited to a rate of 100Hz (for
example, L<Coro::AnyEvent> thread scheduling).
=item * Irssi leaks memory like hell.
Yeah.
=back
Apart from that, documentation is notoriously wrong (e.g. file handles
are not supported by C<input_add>, contrary to documentation), hooking
into irssi has to be done in... weird... ways, but otherwise, Irssi is
lib/AnyEvent/Impl/POE.pm view on Meta::CPAN
eyes) projects or their maintainers is acceptable to him.
This has (I believe) zero effects on the quality or usefulness of his
code, but it does completely undermine his trustworthyness - so don't
blindly believe anything he says, he might have just made it up to suit
his needs (benchmark results, the names of my ten wifes, the length of my
penis, etc. etc.). When in doubt, double-check - not just him, anybody
actually.
Example: L<http://www.nntp.perl.org/group/perl.perl5.porters/2012/01/msg182141.html>.
I challenged him in that thread to provide evidence for his statement by giving at
least two examples, but of course since he just made it up, he couldn't provide any evidence.
=back
On the good side, AnyEvent allows you to write your modules in a 100%
POE-compatible way (bug-for-bug compatible even), without forcing your
module to use POE - it is still open to better event models, of which
there are plenty.
Oh, and one other positive thing:
lib/AnyEvent/Intro.pod view on Meta::CPAN
A typical limitation of existing Perl modules such as L<Net::IRC> is that
they come with their own event loop: In L<Net::IRC>, a program which uses
it needs to start the event loop of L<Net::IRC>. That means that one
cannot integrate this module into a L<Gtk2> GUI for instance, as that
module, too, enforces the use of its own event loop (namely L<Glib>).
Another example is L<LWP>: it provides no event interface at all. It's
a pure blocking HTTP (and FTP etc.) client library, which usually means
that you either have to start another process or have to fork for a HTTP
request, or use threads (e.g. L<Coro::LWP>), if you want to do something
else while waiting for the request to finish.
The motivation behind these designs is often that a module doesn't want
to depend on some complicated XS-module (Net::IRC), or that it doesn't
want to force the user to use some specific event loop at all (LWP), out
of fear of severly limiting the usefulness of the module: If your module
requires Glib, it will not run in a Tk program.
L<AnyEvent> solves this dilemma, by B<not> forcing module authors to
either:
lib/AnyEvent/Intro.pod view on Meta::CPAN
poll => "r", # which event to wait for ("r"ead data)
cb => sub { # what callback to execute
$name = <STDIN>; # read it
}
);
# do something else here
Looks more complicated, and surely is, but the advantage of using events
is that your program can do something else instead of waiting for input
(side note: combining AnyEvent with a thread package such as Coro can
recoup much of the simplicity, effectively getting the best of two
worlds).
Waiting as done in the first example is also called "blocking" the process
because you "block"/keep your process from executing anything else while
you do so.
The second example avoids blocking by only registering interest in a read
event, which is fast and doesn't block your process. The callback will
be called only when data is available and can be read without blocking.
lib/AnyEvent/Log.pm view on Meta::CPAN
sub log_to_warn {
my ($ctx, $path) = @_;
$ctx->log_cb (sub {
warn shift;
0
});
}
# this function is a good example of why threads are a must,
# simply for priority inversion.
sub _log_to_disk {
# eval'uating this at runtime saves 220kb rss - perl has become
# an insane memory waster.
eval q{ # poor man's autoloading {}
sub _log_to_disk {
my ($ctx, $path, $keepopen) = @_;
my $fh;
my @queue;
lib/AnyEvent/Util.pm view on Meta::CPAN
Win32 spoilers: Due to the endlessly sucky and broken native windows
perls (there is no way to cleanly exit a child process on that platform
that doesn't also kill the parent), you have to make sure that your main
program doesn't exit as long as any C<fork_calls> are still in progress,
otherwise the program won't exit. Also, on most windows platforms some
memory will leak for every invocation. We are open for improvements that
don't require XS hackery.
Note that forking can be expensive in large programs (RSS 200MB+). On
windows, it is abysmally slow, do not expect more than 5..20 forks/s on
that sucky platform (note this uses perl's pseudo-threads, so avoid those
like the plague).
Example: poor man's async disk I/O (better use L<AnyEvent::IO> together
with L<IO::AIO>).
fork_call {
open my $fh, "</etc/passwd"
or die "passwd: $!";
local $/;
<$fh>
( run in 0.318 second using v1.01-cache-2.11-cpan-3cd7ad12f66 )