| 1 |
root |
1.1 |
=head1 NAME |
| 2 |
|
|
|
| 3 |
root |
1.76 |
Coro::Event - do events the coro-way, with Event |
| 4 |
root |
1.1 |
|
| 5 |
|
|
=head1 SYNOPSIS |
| 6 |
|
|
|
| 7 |
|
|
use Coro; |
| 8 |
|
|
use Coro::Event; |
| 9 |
|
|
|
| 10 |
|
|
sub keyboard : Coro { |
| 11 |
pcg |
1.21 |
my $w = Coro::Event->io(fd => \*STDIN, poll => 'r'); |
| 12 |
root |
1.1 |
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 |
root |
1.8 |
loop; |
| 22 |
root |
1.1 |
|
| 23 |
root |
1.47 |
# wait for input on stdin for one second |
| 24 |
|
|
|
| 25 |
|
|
Coro::Event::do_io (fd => \*STDIN, timeout => 1) & Event::Watcher::R |
| 26 |
|
|
or die "no input received"; |
| 27 |
|
|
|
| 28 |
root |
1.52 |
# use a separate coroutine for event processing, if impossible in main: |
| 29 |
|
|
Coro::async { Event::loop }; |
| 30 |
|
|
|
| 31 |
root |
1.1 |
=head1 DESCRIPTION |
| 32 |
|
|
|
| 33 |
|
|
This module enables you to create programs using the powerful Event model |
| 34 |
|
|
(and module), while retaining the linear style known from simple or |
| 35 |
|
|
threaded programs. |
| 36 |
|
|
|
| 37 |
|
|
This module provides a method and a function for every watcher type |
| 38 |
|
|
(I<flavour>) (see L<Event>). The only difference between these and the |
| 39 |
|
|
watcher constructors from Event is that you do not specify a callback |
| 40 |
|
|
function - it will be managed by this module. |
| 41 |
|
|
|
| 42 |
|
|
Your application should just create all necessary coroutines and then call |
| 43 |
root |
1.12 |
Coro::Event::loop. |
| 44 |
root |
1.1 |
|
| 45 |
root |
1.37 |
Please note that even programs or modules (such as |
| 46 |
|
|
L<Coro::Handle|Coro::Handle>) that use "traditional" |
| 47 |
|
|
event-based/continuation style will run more efficient with this module |
| 48 |
|
|
then when using only Event. |
| 49 |
|
|
|
| 50 |
root |
1.42 |
=head1 WARNING |
| 51 |
|
|
|
| 52 |
|
|
Please note that Event does not support coroutines or threads. That |
| 53 |
|
|
means that you B<MUST NOT> block in an event callback. Again: In Event |
| 54 |
root |
1.52 |
callbacks, you I<must never ever> call a Coroutine function that blocks |
| 55 |
root |
1.42 |
the current coroutine. |
| 56 |
|
|
|
| 57 |
|
|
While this seems to work superficially, it will eventually cause memory |
| 58 |
root |
1.52 |
corruption and often results in deadlocks. |
| 59 |
|
|
|
| 60 |
|
|
Best practise is to always use B<Coro::unblock_sub> for your callbacks. |
| 61 |
root |
1.42 |
|
| 62 |
root |
1.45 |
=head1 SEMANTICS |
| 63 |
|
|
|
| 64 |
root |
1.46 |
Whenever Event blocks (e.g. in a call to C<one_event>, C<loop> etc.), |
| 65 |
root |
1.45 |
this module cede's to all other coroutines with the same or higher |
| 66 |
|
|
priority. When any coroutines of lower priority are ready, it will not |
| 67 |
|
|
block but run one of them and then check for events. |
| 68 |
|
|
|
| 69 |
|
|
The effect is that coroutines with the same or higher priority than |
| 70 |
|
|
the blocking coroutine will keep Event from checking for events, while |
| 71 |
|
|
coroutines with lower priority are being run, but Event checks for new |
| 72 |
|
|
events after every cede. |
| 73 |
|
|
|
| 74 |
root |
1.42 |
=head1 FUNCTIONS |
| 75 |
|
|
|
| 76 |
root |
1.1 |
=over 4 |
| 77 |
|
|
|
| 78 |
|
|
=cut |
| 79 |
|
|
|
| 80 |
|
|
package Coro::Event; |
| 81 |
|
|
|
| 82 |
root |
1.42 |
no warnings; |
| 83 |
root |
1.1 |
|
| 84 |
|
|
use Carp; |
| 85 |
root |
1.30 |
no warnings; |
| 86 |
root |
1.1 |
|
| 87 |
|
|
use Coro; |
| 88 |
root |
1.8 |
use Event qw(loop unloop); # we are re-exporting this, cooool! |
| 89 |
root |
1.1 |
|
| 90 |
root |
1.30 |
use XSLoader; |
| 91 |
root |
1.1 |
|
| 92 |
root |
1.30 |
use base Exporter::; |
| 93 |
|
|
|
| 94 |
root |
1.41 |
our @EXPORT = qw(loop unloop sweep); |
| 95 |
root |
1.1 |
|
| 96 |
root |
1.2 |
BEGIN { |
| 97 |
root |
1.80 |
our $VERSION = 5.13; |
| 98 |
root |
1.2 |
|
| 99 |
root |
1.13 |
local $^W = 0; # avoid redefine warning for Coro::ready; |
| 100 |
root |
1.30 |
XSLoader::load __PACKAGE__, $VERSION; |
| 101 |
root |
1.2 |
} |
| 102 |
root |
1.1 |
|
| 103 |
root |
1.42 |
=item $w = Coro::Event->flavour (args...) |
| 104 |
root |
1.1 |
|
| 105 |
|
|
Create and return a watcher of the given type. |
| 106 |
|
|
|
| 107 |
|
|
Examples: |
| 108 |
|
|
|
| 109 |
root |
1.77 |
my $reader = Coro::Event->io (fd => $filehandle, poll => 'r'); |
| 110 |
root |
1.1 |
$reader->next; |
| 111 |
|
|
|
| 112 |
|
|
=cut |
| 113 |
|
|
|
| 114 |
|
|
=item $w->next |
| 115 |
|
|
|
| 116 |
root |
1.47 |
Wait for and return the next event of the event queue of the watcher. The |
| 117 |
|
|
returned event objects support two methods only: C<hits> and C<got>, both |
| 118 |
|
|
of which return integers: the number this watcher was hit for this event, |
| 119 |
|
|
and the mask of poll events received. |
| 120 |
root |
1.1 |
|
| 121 |
|
|
=cut |
| 122 |
|
|
|
| 123 |
root |
1.42 |
=item do_flavour args... |
| 124 |
root |
1.1 |
|
| 125 |
root |
1.47 |
Create a watcher of the given type and immediately call it's next method, |
| 126 |
|
|
returning the event. |
| 127 |
|
|
|
| 128 |
|
|
This is less efficient then calling the constructor once and the next |
| 129 |
|
|
method often, but it does save typing sometimes. |
| 130 |
root |
1.1 |
|
| 131 |
|
|
=cut |
| 132 |
|
|
|
| 133 |
|
|
for my $flavour (qw(idle var timer io signal)) { |
| 134 |
|
|
push @EXPORT, "do_$flavour"; |
| 135 |
|
|
my $new = \&{"Event::$flavour"}; |
| 136 |
|
|
my $class = "Coro::Event::$flavour"; |
| 137 |
root |
1.2 |
my $type = $flavour eq "io" ? 1 : 0; |
| 138 |
root |
1.1 |
@{"${class}::ISA"} = (Coro::Event::, "Event::$flavour"); |
| 139 |
|
|
my $coronew = sub { |
| 140 |
|
|
# how does one do method-call-by-name? |
| 141 |
|
|
# my $w = $class->SUPER::$flavour(@_); |
| 142 |
|
|
|
| 143 |
root |
1.10 |
shift eq Coro::Event:: |
| 144 |
root |
1.1 |
or croak "event constructor \"Coro::Event->$flavour\" must be called as a static method"; |
| 145 |
|
|
|
| 146 |
root |
1.10 |
my $w = $new->($class, |
| 147 |
root |
1.49 |
desc => $flavour, |
| 148 |
|
|
@_, |
| 149 |
|
|
parked => 1, |
| 150 |
root |
1.1 |
); |
| 151 |
root |
1.43 |
|
| 152 |
|
|
_install_std_cb $w, $type; |
| 153 |
|
|
|
| 154 |
|
|
# reblessing due to Event being broken |
| 155 |
|
|
bless $w, $class |
| 156 |
root |
1.1 |
}; |
| 157 |
|
|
*{ $flavour } = $coronew; |
| 158 |
|
|
*{"do_$flavour"} = sub { |
| 159 |
|
|
unshift @_, Coro::Event::; |
| 160 |
root |
1.50 |
@_ = &$coronew; |
| 161 |
|
|
&Coro::schedule while &_next; |
| 162 |
root |
1.51 |
$_[0]->cancel; |
| 163 |
root |
1.50 |
&_event |
| 164 |
root |
1.1 |
}; |
| 165 |
|
|
} |
| 166 |
|
|
|
| 167 |
root |
1.50 |
# do schedule in perl to avoid forcing a stack allocation. |
| 168 |
|
|
# this is about 10% slower, though. |
| 169 |
|
|
sub next($) { |
| 170 |
|
|
&Coro::schedule while &_next; |
| 171 |
|
|
&_event |
| 172 |
|
|
} |
| 173 |
|
|
|
| 174 |
root |
1.47 |
sub Coro::Event::Event::hits { $_[0][3] } |
| 175 |
|
|
sub Coro::Event::Event::got { $_[0][4] } |
| 176 |
root |
1.1 |
|
| 177 |
|
|
=item sweep |
| 178 |
|
|
|
| 179 |
|
|
Similar to Event::one_event and Event::sweep: The idle task is called once |
| 180 |
|
|
(this has the effect of jumping back into the Event loop once to serve new |
| 181 |
|
|
events). |
| 182 |
|
|
|
| 183 |
|
|
The reason this function exists is that you sometimes want to serve events |
| 184 |
|
|
while doing other work. Calling C<Coro::cede> does not work because |
| 185 |
|
|
C<cede> implies that the current coroutine is runnable and does not call |
| 186 |
|
|
into the Event dispatcher. |
| 187 |
|
|
|
| 188 |
|
|
=cut |
| 189 |
|
|
|
| 190 |
|
|
sub sweep { |
| 191 |
root |
1.42 |
Event::one_event 0; # for now |
| 192 |
root |
1.1 |
} |
| 193 |
|
|
|
| 194 |
|
|
=item $result = loop([$timeout]) |
| 195 |
|
|
|
| 196 |
|
|
This is the version of C<loop> you should use instead of C<Event::loop> |
| 197 |
|
|
when using this module - it will ensure correct scheduling in the presence |
| 198 |
|
|
of events. |
| 199 |
|
|
|
| 200 |
|
|
=item unloop([$result]) |
| 201 |
|
|
|
| 202 |
|
|
Same as Event::unloop (provided here for your convinience only). |
| 203 |
|
|
|
| 204 |
|
|
=cut |
| 205 |
|
|
|
| 206 |
root |
1.52 |
# very inefficient |
| 207 |
root |
1.77 |
our $IDLE = new Coro sub { |
| 208 |
root |
1.52 |
while () { |
| 209 |
|
|
&Event::one_event; |
| 210 |
|
|
&Coro::schedule; |
| 211 |
|
|
} |
| 212 |
|
|
}; |
| 213 |
root |
1.77 |
$IDLE->{desc} = "[Event idle process]"; |
| 214 |
root |
1.52 |
|
| 215 |
root |
1.77 |
$Coro::idle = $IDLE; |
| 216 |
root |
1.9 |
|
| 217 |
root |
1.1 |
1; |
| 218 |
|
|
|
| 219 |
root |
1.36 |
=back |
| 220 |
|
|
|
| 221 |
root |
1.1 |
=head1 AUTHOR |
| 222 |
|
|
|
| 223 |
root |
1.27 |
Marc Lehmann <schmorp@schmorp.de> |
| 224 |
root |
1.25 |
http://home.schmorp.de/ |
| 225 |
root |
1.1 |
|
| 226 |
|
|
=cut |
| 227 |
|
|
|