Coro::Event - do events the coro-way, with Event
use Coro;
use Coro::Event;
sub keyboard : Coro {
my $w = Coro::Event->io(fd => \*STDIN, poll => 'r');
while() {
print "cmd> ";
my $ev = $w->next; my $cmd = <STDIN>;
unloop unless $cmd ne "";
print "data> ";
my $ev = $w->next; my $data = <STDIN>;
}
}
loop;
# wait for input on stdin for one second
Coro::Event::do_io (fd => \*STDIN, timeout => 1) & Event::Watcher::R
or die "no input received";
# use a separate coroutine for event processing, if impossible in main:
Coro::async { Event::loop };
This module enables you to create programs using the powerful Event model (and module), while retaining the linear style known from simple or threaded programs.
This module provides a method and a function for every watcher type (flavour) (see Event). The only difference between these and the watcher constructors from Event is that you do not specify a callback function - it will be managed by this module.
Your application should just create all necessary coroutines and then call Coro::Event::loop.
Please note that even programs or modules (such as Coro::Handle) that use "traditional" event-based/continuation style will run more efficient with this module then when using only Event.
Please note that Event does not support coroutines or threads. That means that you MUST NOT block in an event callback. Again: In Event callbacks, you must never ever call a Coroutine function that blocks the current coroutine.
While this seems to work superficially, it will eventually cause memory corruption and often results in deadlocks.
Best practise is to always use Coro::unblock_sub for your callbacks.
Whenever Event blocks (e.g. in a call to one_event, loop etc.),
this module cede's to all other coroutines with the same or higher
priority. When any coroutines of lower priority are ready, it will not
block but run one of them and then check for events.
The effect is that coroutines with the same or higher priority than the blocking coroutine will keep Event from checking for events, while coroutines with lower priority are being run, but Event checks for new events after every cede.
Create and return a watcher of the given type.
Examples:
my $reader = Coro::Event->io (fd => $filehandle, poll => 'r'); $reader->next;
Wait for and return the next event of the event queue of the watcher. The
returned event objects support two methods only: hits and got, both
of which return integers: the number this watcher was hit for this event,
and the mask of poll events received.
Create a watcher of the given type and immediately call it's next method, returning the event.
This is less efficient then calling the constructor once and the next method often, but it does save typing sometimes.
Similar to Event::one_event and Event::sweep: The idle task is called once (this has the effect of jumping back into the Event loop once to serve new events).
The reason this function exists is that you sometimes want to serve events
while doing other work. Calling Coro::cede does not work because
cede implies that the current coroutine is runnable and does not call
into the Event dispatcher.
loop you should use instead of Event::loop
when using this module - it will ensure correct scheduling in the presence
of events.
Same as Event::unloop (provided here for your convinience only).
Marc Lehmann <schmorp@schmorp.de> http://home.schmorp.de/