Coro::AnyEvent - integrate threads into AnyEvent
use Coro; use Coro::AnyEvent; # use coro within an AnyEvent environment
When one naively starts to use threads in Perl, one will quickly run into the problem that threads that block on a syscall (sleeping, reading from a socket etc.) will block all threads.
If one then uses an event loop, the problem is that the event loop has no knowledge of threads and will not run them before it polls for new events, again blocking the whole process.
This module integrates threads into any event loop supported by AnyEvent, combining event-based programming with coroutine-based programming in a natural way.
All you have to do is use Coro::AnyEvent, run the event loop of your choice in some thread and then you can run threads freely.
This module autodetects the event loop used (by relying on AnyEvent) and will either automatically defer to the high-performance Coro::EV or Coro::Event modules, or will use a generic integration into any event loop supported by AnyEvent.
Note that if you need to wait for a single event, the rouse functions will come in handy (see the Coro manpage for details):
# wait for single SIGINT
{
my $int_w = AnyEvent->signal (signal => "INT", cb => Coro::rouse_cb);
Coro::rouse_wait;
}
Coro::AnyEvent offers a few functions that might be useful.
This call will block the current thread until the event loop has polled for new events and instructs the event loop to poll for new events once, without blocking.
Note that this call will not actually execute the poll, just block until new events have been polled, so other threads will have a chance to run.
This is useful when you have a thread that does some computations, but you still want to poll for new events from time to time. Simply call poll from time to time:
my $long_calc = async {
for (1..10000) {
Coro::AnyEvent::poll:
# do some stuff, make sure it takes at least 0.001s or so
}
}
Although you should also consider idle or idle_upto in such cases.
This blocks the current thread for at least the given number of seconds.
This call is similar to poll in that it will also poll for events. Unlike poll, it will only resume the thread once there are no events to handle anymore, i.e. when the process is otherwise idle.
Like idle, but with a maximum waiting time.
If your process is busy handling events, calling idle can mean that your thread will never be resumed. To avoid this, you can use idle_upto and specify a timeout, after which your thread will be resumed even if the process is completely busy.
Blocks the current thread until the given file handle (or file descriptor) becomes readable (or writable), or the given timeout has elapsed, whichever happens first. No timeout counts as infinite timeout.
Returns true when the file handle became ready, false when a timeout occured.
Note that these functions are quite inefficient as compared to using a single watcher (they recreate watchers on every invocation) or compared to using Coro::Handle.
Note also that they only work for sources that have reasonable non-blocking behaviour (e.g. not files).
Example: wait until STDIN becomes readable, then quit the program.
use Coro::AnyEvent; print "press enter to quit...\n"; Coro::AnyEvent::readable *STDIN; exit 0;
Unfortunately, few event loops (basically only EV and Event) support the kind of integration required for smooth operations well, and consequently, AnyEvent cannot completely offer the functionality required by this module, so we need to improvise.
Here is what this module does when it has to work with other event loops:
Each time a thread is put into the ready queue (and there are no other threads in the ready queue), a timer with an after value of 0 is registered with AnyEvent.
This creates something similar to an idle watcher, i.e. a watcher that keeps the event loop from blocking but still polls for new events. (Unfortunately, some badly designed event loops (e.g. Event::Lib) don't support a timeout of 0 and will always block for a bit).
The callback for that timer will cede to other threads of the same or higher priority for as long as such threads exists. This has the effect of running all threads that have work to do until all threads block to wait for external events.
If no threads of equal or higher priority are ready, it will cede to any thread, but only once. This has the effect of running lower-priority threads as well, but it will not keep higher priority threads from receiving new events.
The priority used is simply the priority of the thread that runs the event loop, usually the main program, which usually has a priority of 0. Note that Coro::AnyEvent does not run an event loop for you, so unless the main program runs one, there will simply be no event loop to cede to (event handling will still work, somewhat inefficiently, but any thread will have a higher priority than event handling in that case).
In addition to hooking into ready, this module will also provide a $Coro::idle handler that runs the event loop. It is best not to take advantage of this too often, as this is rather inefficient, but it should work perfectly fine.
This module installs overrides for AnyEvent's condvars. That is, when the module is loaded it will provide its own condition variables. This makes them coroutine-safe, i.e. you can safely block on them from within a coroutine.
As unblock_sub cannot be used by this module (as it is the module that implements it, basically), you must not call into the event loop recursively from any coroutine. This is not usually a difficult restriction to live with, just use condvars, unblock_sub or other means of inter-coroutine-communications.
If you use a module that supports AnyEvent (or uses the same event loop as AnyEvent, making the compatible), and it offers callbacks of any kind, then you must not block in them, either (or use e.g. unblock_sub), see the description of unblock_sub in the Coro module.
This also means that you should load the module as early as possible, as only condvars created after this module has been loaded will work correctly.
AnyEvent, to see which event loops are supported, Coro::EV and Coro::Event for more efficient and more correct solutions (they will be used automatically if applicable).
Marc Lehmann <schmorp@schmorp.de> http://home.schmorp.de/
