1 |
=head1 NAME |
2 |
|
3 |
Coro - coroutine process abstraction |
4 |
|
5 |
=head1 SYNOPSIS |
6 |
|
7 |
use Coro; |
8 |
|
9 |
async { |
10 |
# some asynchronous thread of execution |
11 |
}; |
12 |
|
13 |
# alternatively create an async process like this: |
14 |
|
15 |
sub some_func : Coro { |
16 |
# some more async code |
17 |
} |
18 |
|
19 |
cede; |
20 |
|
21 |
=head1 DESCRIPTION |
22 |
|
23 |
This module collection manages coroutines. Coroutines are similar to |
24 |
Threads but don't run in parallel. |
25 |
|
26 |
This module is still experimental, see the BUGS section below. |
27 |
|
28 |
In this module, coroutines are defined as "callchain + lexical variables |
29 |
+ @_ + $_ + $@ + $^W), that is, a coroutine has it's own callchain, it's |
30 |
own set of lexicals and it's own set of perl's most important global |
31 |
variables. |
32 |
|
33 |
WARNING: When using this module, make sure that, at program end, no |
34 |
coroutines are still running OR just call exit before falling off the |
35 |
end. The reason for this is that some coroutine of yours might have called |
36 |
into a C function, and falling off the end of main:: results in returning |
37 |
to that C function instead if to the main C interpreter. |
38 |
|
39 |
WARNING: Unless you really know what you are doing, do NOT do context |
40 |
switches inside callbacks from the XS level. The reason for this is |
41 |
similar to the reason above: A callback calls a perl function, this |
42 |
perl function does a context switch, some other callback is called, the |
43 |
original function returns from it - to what? To the wrong XS function, |
44 |
with totally different return values. Unfortunately, this includes |
45 |
callbacks done by perl itself (tie'd variables!). |
46 |
|
47 |
The only workaround for this is to do coroutines on C level. |
48 |
|
49 |
=cut |
50 |
|
51 |
package Coro; |
52 |
|
53 |
use Coro::State; |
54 |
|
55 |
use base Exporter; |
56 |
|
57 |
$VERSION = 0.10; |
58 |
|
59 |
@EXPORT = qw(async cede schedule terminate current); |
60 |
@EXPORT_OK = qw($current); |
61 |
|
62 |
{ |
63 |
my @async; |
64 |
|
65 |
# this way of handling attributes simply is NOT scalable ;() |
66 |
sub import { |
67 |
Coro->export_to_level(1, @_); |
68 |
my $old = *{(caller)[0]."::MODIFY_CODE_ATTRIBUTES"}{CODE}; |
69 |
*{(caller)[0]."::MODIFY_CODE_ATTRIBUTES"} = sub { |
70 |
my ($package, $ref) = (shift, shift); |
71 |
my @attrs; |
72 |
for (@_) { |
73 |
if ($_ eq "Coro") { |
74 |
push @async, $ref; |
75 |
} else { |
76 |
push @attrs, $_; |
77 |
} |
78 |
} |
79 |
return $old ? $old->($package, $ref, @attrs) : @attrs; |
80 |
}; |
81 |
} |
82 |
|
83 |
sub INIT { |
84 |
&async(pop @async) while @async; |
85 |
} |
86 |
} |
87 |
|
88 |
=item $main |
89 |
|
90 |
This coroutine represents the main program. |
91 |
|
92 |
=cut |
93 |
|
94 |
our $main = new Coro; |
95 |
|
96 |
=item $current (or as function: current) |
97 |
|
98 |
The current coroutine (the last coroutine switched to). The initial value is C<$main> (of course). |
99 |
|
100 |
=cut |
101 |
|
102 |
# maybe some other module used Coro::Specific before... |
103 |
if ($current) { |
104 |
$main->{specific} = $current->{specific}; |
105 |
} |
106 |
|
107 |
our $current = $main; |
108 |
|
109 |
sub current() { $current } |
110 |
|
111 |
=item $idle |
112 |
|
113 |
The coroutine to switch to when no other coroutine is running. The default |
114 |
implementation prints "FATAL: deadlock detected" and exits. |
115 |
|
116 |
=cut |
117 |
|
118 |
# should be done using priorities :( |
119 |
our $idle = new Coro sub { |
120 |
print STDERR "FATAL: deadlock detected\n"; |
121 |
exit(51); |
122 |
}; |
123 |
|
124 |
# we really need priorities... |
125 |
my @ready; # the ready queue. hehe, rather broken ;) |
126 |
|
127 |
# static methods. not really. |
128 |
|
129 |
=head2 STATIC METHODS |
130 |
|
131 |
Static methods are actually functions that operate on the current process only. |
132 |
|
133 |
=over 4 |
134 |
|
135 |
=item async { ... } [@args...] |
136 |
|
137 |
Create a new asynchronous process and return it's process object |
138 |
(usually unused). When the sub returns the new process is automatically |
139 |
terminated. |
140 |
|
141 |
# create a new coroutine that just prints its arguments |
142 |
async { |
143 |
print "@_\n"; |
144 |
} 1,2,3,4; |
145 |
|
146 |
The coderef you submit MUST NOT be a closure that refers to variables |
147 |
in an outer scope. This does NOT work. Pass arguments into it instead. |
148 |
|
149 |
=cut |
150 |
|
151 |
sub async(&@) { |
152 |
my $pid = new Coro @_; |
153 |
$pid->ready; |
154 |
$pid; |
155 |
} |
156 |
|
157 |
=item schedule |
158 |
|
159 |
Calls the scheduler. Please note that the current process will not be put |
160 |
into the ready queue, so calling this function usually means you will |
161 |
never be called again. |
162 |
|
163 |
=cut |
164 |
|
165 |
my $prev; |
166 |
|
167 |
sub schedule { |
168 |
# should be done using priorities :( |
169 |
($prev, $current) = ($current, shift @ready || $idle); |
170 |
Coro::State::transfer($prev, $current); |
171 |
} |
172 |
|
173 |
=item cede |
174 |
|
175 |
"Cede" to other processes. This function puts the current process into the |
176 |
ready queue and calls C<schedule>, which has the effect of giving up the |
177 |
current "timeslice" to other coroutines of the same or higher priority. |
178 |
|
179 |
=cut |
180 |
|
181 |
sub cede { |
182 |
$current->ready; |
183 |
&schedule; |
184 |
} |
185 |
|
186 |
=item terminate |
187 |
|
188 |
Terminates the current process. |
189 |
|
190 |
Future versions of this function will allow result arguments. |
191 |
|
192 |
=cut |
193 |
|
194 |
sub terminate { |
195 |
my $self = $current; |
196 |
$self->{_results} = [@_]; |
197 |
$current = shift @ready || $idle; |
198 |
Coro::State::transfer(delete $self->{_coro_state}, $current); |
199 |
# cannot return |
200 |
die; |
201 |
} |
202 |
|
203 |
=back |
204 |
|
205 |
# dynamic methods |
206 |
|
207 |
=head2 PROCESS METHODS |
208 |
|
209 |
These are the methods you can call on process objects. |
210 |
|
211 |
=over 4 |
212 |
|
213 |
=item new Coro \&sub [, @args...] |
214 |
|
215 |
Create a new process and return it. When the sub returns the process |
216 |
automatically terminates. To start the process you must first put it into |
217 |
the ready queue by calling the ready method. |
218 |
|
219 |
The coderef you submit MUST NOT be a closure that refers to variables |
220 |
in an outer scope. This does NOT work. Pass arguments into it instead. |
221 |
|
222 |
=cut |
223 |
|
224 |
sub _newcoro { |
225 |
terminate &{+shift}; |
226 |
} |
227 |
|
228 |
sub new { |
229 |
my $class = shift; |
230 |
bless { |
231 |
_coro_state => (new Coro::State $_[0] && \&_newcoro, @_), |
232 |
}, $class; |
233 |
} |
234 |
|
235 |
=item $process->ready |
236 |
|
237 |
Put the current process into the ready queue. |
238 |
|
239 |
=cut |
240 |
|
241 |
sub ready { |
242 |
push @ready, $_[0]; |
243 |
} |
244 |
|
245 |
=back |
246 |
|
247 |
=cut |
248 |
|
249 |
1; |
250 |
|
251 |
=head1 BUGS/LIMITATIONS |
252 |
|
253 |
- could be faster, especially when the core would introduce special |
254 |
support for coroutines (like it does for threads). |
255 |
- there is still a memleak on coroutine termination that I could not |
256 |
identify. Could be as small as a single SV. |
257 |
- this module is not well-tested. |
258 |
- if variables or arguments "disappear" (become undef) or become |
259 |
corrupted please contact the author so he cen iron out the |
260 |
remaining bugs. |
261 |
- this module is not thread-safe. You must only ever use this module from |
262 |
the same thread (this requirement might be loosened in the future to |
263 |
allow per-thread schedulers, but Coro::State does not yet allow this). |
264 |
|
265 |
=head1 SEE ALSO |
266 |
|
267 |
L<Coro::Channel>, L<Coro::Cont>, L<Coro::Specific>, L<Coro::Semaphore>, |
268 |
L<Coro::Signal>, L<Coro::State>, L<Coro::Event>. |
269 |
|
270 |
=head1 AUTHOR |
271 |
|
272 |
Marc Lehmann <pcg@goof.com> |
273 |
http://www.goof.com/pcg/marc/ |
274 |
|
275 |
=cut |
276 |
|