ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/Coro/Coro.pm
(Generate patch)

Comparing Coro/Coro.pm (file contents):
Revision 1.7 by root, Fri Jul 13 13:05:38 2001 UTC vs.
Revision 1.42 by root, Tue Nov 6 20:37:20 2001 UTC

1=head1 NAME 1=head1 NAME
2 2
3Coro - create and manage simple coroutines 3Coro - coroutine process abstraction
4 4
5=head1 SYNOPSIS 5=head1 SYNOPSIS
6 6
7 use Coro; 7 use Coro;
8 8
9 $new = new Coro sub { 9 async {
10 print "in coroutine, switching back\n"; 10 # some asynchronous thread of execution
11 $new->transfer($main);
12 print "in coroutine again, switching back\n";
13 $new->transfer($main);
14 }; 11 };
15 12
16 $main = new Coro; 13 # alternatively create an async process like this:
17 14
18 print "in main, switching to coroutine\n"; 15 sub some_func : Coro {
19 $main->transfer($new); 16 # some more async code
20 print "back in main, switch to coroutine again\n"; 17 }
21 $main->transfer($new); 18
22 print "back in main\n"; 19 cede;
23 20
24=head1 DESCRIPTION 21=head1 DESCRIPTION
25 22
26This module implements coroutines. Coroutines, similar to continuations, 23This module collection manages coroutines. Coroutines are similar to
27allow you to run more than one "thread of execution" in parallel. Unlike 24threads but don't run in parallel.
28threads this, only voluntary switching is used so locking problems are
29greatly reduced.
30 25
31Although this is the "main" module of the Coro family it provides only 26In this module, coroutines are defined as "callchain + lexical variables
32low-level functionality. See L<Coro::Process> and related modules for a 27+ @_ + $_ + $@ + $^W + C stack), that is, a coroutine has it's own
33more useful process abstraction including scheduling. 28callchain, it's own set of lexicals and it's own set of perl's most
29important global variables.
30
31=cut
32
33package Coro;
34
35no warnings qw(uninitialized);
36
37use Coro::State;
38
39use base Exporter;
40
41$VERSION = 0.52;
42
43@EXPORT = qw(async cede schedule terminate current);
44%EXPORT_TAGS = (
45 prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)],
46);
47@EXPORT_OK = @{$EXPORT_TAGS{prio}};
48
49{
50 my @async;
51 my $init;
52
53 # this way of handling attributes simply is NOT scalable ;()
54 sub import {
55 Coro->export_to_level(1, @_);
56 my $old = *{(caller)[0]."::MODIFY_CODE_ATTRIBUTES"}{CODE};
57 *{(caller)[0]."::MODIFY_CODE_ATTRIBUTES"} = sub {
58 my ($package, $ref) = (shift, shift);
59 my @attrs;
60 for (@_) {
61 if ($_ eq "Coro") {
62 push @async, $ref;
63 unless ($init++) {
64 eval q{
65 sub INIT {
66 &async(pop @async) while @async;
67 }
68 };
69 }
70 } else {
71 push @attrs, $_;
72 }
73 }
74 return $old ? $old->($package, $ref, @attrs) : @attrs;
75 };
76 }
77
78}
79
80=item $main
81
82This coroutine represents the main program.
83
84=cut
85
86our $main = new Coro;
87
88=item $current (or as function: current)
89
90The current coroutine (the last coroutine switched to). The initial value is C<$main> (of course).
91
92=cut
93
94# maybe some other module used Coro::Specific before...
95if ($current) {
96 $main->{specific} = $current->{specific};
97}
98
99our $current = $main;
100
101sub current() { $current }
102
103=item $idle
104
105The coroutine to switch to when no other coroutine is running. The default
106implementation prints "FATAL: deadlock detected" and exits.
107
108=cut
109
110# should be done using priorities :(
111our $idle = new Coro sub {
112 print STDERR "FATAL: deadlock detected\n";
113 exit(51);
114};
115
116# this coroutine is necessary because a coroutine
117# cannot destroy itself.
118my @destroy;
119my $manager;
120$manager = new Coro sub {
121 while() {
122 # by overwriting the state object with the manager we destroy it
123 # while still being able to schedule this coroutine (in case it has
124 # been readied multiple times. this is harmless since the manager
125 # can be called as many times as neccessary and will always
126 # remove itself from the runqueue
127 while (@destroy) {
128 my $coro = pop @destroy;
129 $coro->{status} ||= [];
130 $_->ready for @{delete $coro->{join} || []};
131 $coro->{_coro_state} = $manager->{_coro_state};
132 }
133 &schedule;
134 }
135};
136
137# static methods. not really.
138
139=head2 STATIC METHODS
140
141Static methods are actually functions that operate on the current process only.
34 142
35=over 4 143=over 4
36 144
37=cut 145=item async { ... } [@args...]
38 146
39package Coro; 147Create a new asynchronous process and return it's process object
148(usually unused). When the sub returns the new process is automatically
149terminated.
40 150
41BEGIN { 151 # create a new coroutine that just prints its arguments
42 $VERSION = 0.03; 152 async {
153 print "@_\n";
154 } 1,2,3,4;
43 155
44 require XSLoader; 156The coderef you submit MUST NOT be a closure that refers to variables
45 XSLoader::load Coro, $VERSION; 157in an outer scope. This does NOT work. Pass arguments into it instead.
46}
47 158
48=item $coro = new [$coderef [, @args]]
49
50Create a new coroutine and return it. The first C<transfer> call to this
51coroutine will start execution at the given coderef. If, the subroutine
52returns it will be executed again.
53
54If the coderef is omitted this function will create a new "empty"
55coroutine, i.e. a coroutine that cannot be transfered to but can be used
56to save the current coroutine in.
57
58=cut 159=cut
160
161sub async(&@) {
162 my $pid = new Coro @_;
163 $manager->ready; # this ensures that the stack is cloned from the manager
164 $pid->ready;
165 $pid;
166}
167
168=item schedule
169
170Calls the scheduler. Please note that the current process will not be put
171into the ready queue, so calling this function usually means you will
172never be called again.
173
174=cut
175
176=item cede
177
178"Cede" to other processes. This function puts the current process into the
179ready queue and calls C<schedule>, which has the effect of giving up the
180current "timeslice" to other coroutines of the same or higher priority.
181
182=cut
183
184=item terminate [arg...]
185
186Terminates the current process.
187
188Future versions of this function will allow result arguments.
189
190=cut
191
192sub terminate {
193 $current->{status} = [@_];
194 $current->cancel;
195 &schedule;
196 die; # NORETURN
197}
198
199=back
200
201# dynamic methods
202
203=head2 PROCESS METHODS
204
205These are the methods you can call on process objects.
206
207=over 4
208
209=item new Coro \&sub [, @args...]
210
211Create a new process and return it. When the sub returns the process
212automatically terminates as if C<terminate> with the returned values were
213called. To make the process run you must first put it into the ready queue
214by calling the ready method.
215
216=cut
217
218sub _newcoro {
219 terminate &{+shift};
220}
59 221
60sub new { 222sub new {
61 my $class = $_[0]; 223 my $class = shift;
62 my $proc = $_[1] || sub { die "tried to transfer to an empty coroutine" }; 224 bless {
63 bless _newprocess { 225 _coro_state => (new Coro::State $_[0] && \&_newcoro, @_),
64 do {
65 eval { &$proc };
66 if ($@) {
67 $error_msg = $@;
68 $error_coro = _newprocess { };
69 &transfer($error_coro, $error);
70 }
71 } while (1);
72 }, $class; 226 }, $class;
73} 227}
74 228
75=item $prev->transfer($next) 229=item $process->ready
76 230
77Save the state of the current subroutine in C<$prev> and switch to the 231Put the given process into the ready queue.
78coroutine saved in C<$next>.
79 232
80The "state" of a subroutine only ever includes scope, i.e. lexical 233=cut
81variables and the current execution state. It does not save/restore any
82global variables such as C<$_> or C<$@> or any other special or non
83special variables. So remember that every function call that might call
84C<transfer> (such as C<Coro::Channel::put>) might clobber any global
85and/or special variables. Yes, this is by design ;) You cna always create
86your own process abstraction model that saves these variables.
87 234
88The easiest way to do this is to create your own scheduling primitive like this: 235=item $process->cancel
89 236
90 sub schedule { 237Like C<terminate>, but terminates the specified process instead.
91 local ($_, $@, ...); 238
92 $old->transfer($new); 239=cut
240
241sub cancel {
242 push @destroy, $_[0];
243 $manager->ready;
244 &schedule if $current == $_[0];
245}
246
247=item $process->join
248
249Wait until the coroutine terminates and return any values given to the
250C<terminate> function. C<join> can be called multiple times from multiple
251processes.
252
253=cut
254
255sub join {
256 my $self = shift;
257 unless ($self->{status}) {
258 push @{$self->{join}}, $current;
259 &schedule;
93 } 260 }
94 261 wantarray ? @{$self->{status}} : $self->{status}[0];
95=cut
96
97# I call the _transfer function from a perl function
98# because that way perl saves all important things on
99# the stack. Actually, I'd do it from within XS, but
100# I couldn't get it to work.
101sub transfer {
102 _transfer($_[0], $_[1]);
103} 262}
104 263
105=item $error, $error_msg, $error_coro 264=item $oldprio = $process->prio($newprio)
106 265
107This coroutine will be called on fatal errors. C<$error_msg> and 266Sets (or gets, if the argument is missing) the priority of the
108C<$error_coro> return the error message and the error-causing coroutine 267process. Higher priority processes get run before lower priority
109(NOT an object) respectively. This API might change. 268processes. Priorities are smalled signed integer (currently -4 .. +3),
269that you can refer to using PRIO_xxx constants (use the import tag :prio
270to get then):
110 271
111=cut 272 PRIO_MAX > PRIO_HIGH > PRIO_NORMAL > PRIO_LOW > PRIO_IDLE > PRIO_MIN
273 3 > 1 > 0 > -1 > -3 > -4
112 274
113$error_msg = 275 # set priority to HIGH
114$error_coro = undef; 276 current->prio(PRIO_HIGH);
115 277
116$error = _newprocess { 278The idle coroutine ($Coro::idle) always has a lower priority than any
117 print STDERR "FATAL: $error_msg\nprogram aborted\n"; 279existing coroutine.
118 exit 50; 280
119}; 281Changing the priority of the current process will take effect immediately,
282but changing the priority of processes in the ready queue (but not
283running) will only take effect after the next schedule (of that
284process). This is a bug that will be fixed in some future version.
285
286=cut
287
288sub prio {
289 my $old = $_[0]{prio};
290 $_[0]{prio} = $_[1] if @_ > 1;
291 $old;
292}
293
294=item $newprio = $process->nice($change)
295
296Similar to C<prio>, but subtract the given value from the priority (i.e.
297higher values mean lower priority, just as in unix).
298
299=cut
300
301sub nice {
302 $_[0]{prio} -= $_[1];
303}
304
305=item $olddesc = $process->desc($newdesc)
306
307Sets (or gets in case the argument is missing) the description for this
308process. This is just a free-form string you can associate with a process.
309
310=cut
311
312sub desc {
313 my $old = $_[0]{desc};
314 $_[0]{desc} = $_[1] if @_ > 1;
315 $old;
316}
317
318=back
319
320=cut
120 321
1211; 3221;
122 323
123=back 324=head1 BUGS/LIMITATIONS
124 325
125=head1 BUGS 326 - you must make very sure that no coro is still active on global destruction.
126 327 very bad things might happen otherwise (usually segfaults).
127This module has not yet been extensively tested. 328 - this module is not thread-safe. You should only ever use this module from
329 the same thread (this requirement might be loosened in the future to
330 allow per-thread schedulers, but Coro::State does not yet allow this).
128 331
129=head1 SEE ALSO 332=head1 SEE ALSO
130 333
131L<Coro::Process>, L<Coro::Signal>. 334L<Coro::Channel>, L<Coro::Cont>, L<Coro::Specific>, L<Coro::Semaphore>,
335L<Coro::Signal>, L<Coro::State>, L<Coro::Event>, L<Coro::RWLock>,
336L<Coro::Handle>, L<Coro::Socket>.
132 337
133=head1 AUTHOR 338=head1 AUTHOR
134 339
135 Marc Lehmann <pcg@goof.com> 340 Marc Lehmann <pcg@goof.com>
136 http://www.goof.com/pcg/marc/ 341 http://www.goof.com/pcg/marc/

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines