| 1 |
=head1 NAME |
| 2 |
|
| 3 |
Coro::Event - do events the coro-way |
| 4 |
|
| 5 |
=head1 SYNOPSIS |
| 6 |
|
| 7 |
use Coro; |
| 8 |
use Coro::Event; |
| 9 |
|
| 10 |
sub keyboard : Coro { |
| 11 |
my $w = Coro::Event->io(fd => \*STDIN, poll => 'r'); |
| 12 |
while() { |
| 13 |
print "cmd> "; |
| 14 |
my $ev = $w->next; my $cmd = <STDIN>; |
| 15 |
unloop unless $cmd ne ""; |
| 16 |
print "data> "; |
| 17 |
my $ev = $w->next; my $data = <STDIN>; |
| 18 |
} |
| 19 |
} |
| 20 |
|
| 21 |
loop; |
| 22 |
|
| 23 |
=head1 DESCRIPTION |
| 24 |
|
| 25 |
This module enables you to create programs using the powerful Event model |
| 26 |
(and module), while retaining the linear style known from simple or |
| 27 |
threaded programs. |
| 28 |
|
| 29 |
This module provides a method and a function for every watcher type |
| 30 |
(I<flavour>) (see L<Event>). The only difference between these and the |
| 31 |
watcher constructors from Event is that you do not specify a callback |
| 32 |
function - it will be managed by this module. |
| 33 |
|
| 34 |
Your application should just create all necessary coroutines and then call |
| 35 |
Coro::Event::loop. |
| 36 |
|
| 37 |
Please note that even programs or modules (such as |
| 38 |
L<Coro::Handle|Coro::Handle>) that use "traditional" |
| 39 |
event-based/continuation style will run more efficient with this module |
| 40 |
then when using only Event. |
| 41 |
|
| 42 |
=head1 WARNING |
| 43 |
|
| 44 |
Please note that Event does not support coroutines or threads. That |
| 45 |
means that you B<MUST NOT> block in an event callback. Again: In Event |
| 46 |
callbacks, you I<must never ever> call a Coroutine fucntion that blocks |
| 47 |
the current coroutine. |
| 48 |
|
| 49 |
While this seems to work superficially, it will eventually cause memory |
| 50 |
corruption. |
| 51 |
|
| 52 |
=head1 FUNCTIONS |
| 53 |
|
| 54 |
=over 4 |
| 55 |
|
| 56 |
=cut |
| 57 |
|
| 58 |
package Coro::Event; |
| 59 |
|
| 60 |
no warnings; |
| 61 |
|
| 62 |
use Carp; |
| 63 |
no warnings; |
| 64 |
|
| 65 |
use Coro; |
| 66 |
use Coro::Timer; |
| 67 |
use Event qw(loop unloop); # we are re-exporting this, cooool! |
| 68 |
|
| 69 |
use XSLoader; |
| 70 |
|
| 71 |
use base Exporter::; |
| 72 |
|
| 73 |
our @EXPORT = qw(loop unloop sweep); |
| 74 |
|
| 75 |
BEGIN { |
| 76 |
our $VERSION = 1.9; |
| 77 |
|
| 78 |
local $^W = 0; # avoid redefine warning for Coro::ready; |
| 79 |
XSLoader::load __PACKAGE__, $VERSION; |
| 80 |
} |
| 81 |
|
| 82 |
=item $w = Coro::Event->flavour (args...) |
| 83 |
|
| 84 |
Create and return a watcher of the given type. |
| 85 |
|
| 86 |
Examples: |
| 87 |
|
| 88 |
my $reader = Coro::Event->io(fd => $filehandle, poll => 'r'); |
| 89 |
$reader->next; |
| 90 |
|
| 91 |
=cut |
| 92 |
|
| 93 |
=item $w->next |
| 94 |
|
| 95 |
Return the next event of the event queue of the watcher. |
| 96 |
|
| 97 |
=cut |
| 98 |
|
| 99 |
=item do_flavour args... |
| 100 |
|
| 101 |
Create a watcher of the given type and immediately call it's next |
| 102 |
method. This is less efficient then calling the constructor once and the |
| 103 |
next method often, but it does save typing sometimes. |
| 104 |
|
| 105 |
=cut |
| 106 |
|
| 107 |
for my $flavour (qw(idle var timer io signal)) { |
| 108 |
push @EXPORT, "do_$flavour"; |
| 109 |
my $new = \&{"Event::$flavour"}; |
| 110 |
my $class = "Coro::Event::$flavour"; |
| 111 |
my $type = $flavour eq "io" ? 1 : 0; |
| 112 |
@{"${class}::ISA"} = (Coro::Event::, "Event::$flavour"); |
| 113 |
my $coronew = sub { |
| 114 |
# how does one do method-call-by-name? |
| 115 |
# my $w = $class->SUPER::$flavour(@_); |
| 116 |
|
| 117 |
shift eq Coro::Event:: |
| 118 |
or croak "event constructor \"Coro::Event->$flavour\" must be called as a static method"; |
| 119 |
|
| 120 |
my $w = $new->($class, |
| 121 |
desc => $flavour, |
| 122 |
@_, |
| 123 |
parked => 1, |
| 124 |
); |
| 125 |
|
| 126 |
_install_std_cb $w, $type; |
| 127 |
|
| 128 |
# reblessing due to Event being broken |
| 129 |
bless $w, $class |
| 130 |
}; |
| 131 |
*{ $flavour } = $coronew; |
| 132 |
*{"do_$flavour"} = sub { |
| 133 |
unshift @_, Coro::Event::; |
| 134 |
my $e = &$coronew->next; |
| 135 |
$e->cancel; # $e === $e->w |
| 136 |
$e |
| 137 |
}; |
| 138 |
} |
| 139 |
|
| 140 |
# do schedule in perl to avoid forcign a stack allocation. |
| 141 |
# this is about 10% slower, though. |
| 142 |
sub next($) { |
| 143 |
&Coro::schedule while &_next; |
| 144 |
|
| 145 |
$_[0] |
| 146 |
} |
| 147 |
|
| 148 |
sub Coro::Event::w { $_[0] } |
| 149 |
sub Coro::Event::prio { $_[0]{Coro::Event}[3] } |
| 150 |
sub Coro::Event::hits { $_[0]{Coro::Event}[4] } |
| 151 |
sub Coro::Event::got { $_[0]{Coro::Event}[5] } |
| 152 |
|
| 153 |
=item sweep |
| 154 |
|
| 155 |
Similar to Event::one_event and Event::sweep: The idle task is called once |
| 156 |
(this has the effect of jumping back into the Event loop once to serve new |
| 157 |
events). |
| 158 |
|
| 159 |
The reason this function exists is that you sometimes want to serve events |
| 160 |
while doing other work. Calling C<Coro::cede> does not work because |
| 161 |
C<cede> implies that the current coroutine is runnable and does not call |
| 162 |
into the Event dispatcher. |
| 163 |
|
| 164 |
=cut |
| 165 |
|
| 166 |
sub sweep { |
| 167 |
Event::one_event 0; # for now |
| 168 |
} |
| 169 |
|
| 170 |
=item $result = loop([$timeout]) |
| 171 |
|
| 172 |
This is the version of C<loop> you should use instead of C<Event::loop> |
| 173 |
when using this module - it will ensure correct scheduling in the presence |
| 174 |
of events. |
| 175 |
|
| 176 |
=item unloop([$result]) |
| 177 |
|
| 178 |
Same as Event::unloop (provided here for your convinience only). |
| 179 |
|
| 180 |
=cut |
| 181 |
|
| 182 |
$Coro::idle = \&Event::one_event; # inefficient |
| 183 |
|
| 184 |
1; |
| 185 |
|
| 186 |
=back |
| 187 |
|
| 188 |
=head1 AUTHOR |
| 189 |
|
| 190 |
Marc Lehmann <schmorp@schmorp.de> |
| 191 |
http://home.schmorp.de/ |
| 192 |
|
| 193 |
=cut |
| 194 |
|
