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.25 by root, Wed Jul 25 21:12:57 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 26This module is still experimental, see the BUGS section below.
32low-level functionality. See L<Coro::Process> and related modules for a 27
33more useful process abstraction including scheduling. 28In this module, coroutines are defined as "callchain + lexical variables
29+ @_ + $_ + $@ + $^W + C stack), that is, a coroutine has it's own
30callchain, it's own set of lexicals and it's own set of perl's most
31important global variables.
32
33=cut
34
35package Coro;
36
37use Coro::State;
38
39use base Exporter;
40
41$VERSION = 0.12;
42
43@EXPORT = qw(async cede schedule terminate current);
44@EXPORT_OK = qw($current);
45
46{
47 my @async;
48
49 # this way of handling attributes simply is NOT scalable ;()
50 sub import {
51 Coro->export_to_level(1, @_);
52 my $old = *{(caller)[0]."::MODIFY_CODE_ATTRIBUTES"}{CODE};
53 *{(caller)[0]."::MODIFY_CODE_ATTRIBUTES"} = sub {
54 my ($package, $ref) = (shift, shift);
55 my @attrs;
56 for (@_) {
57 if ($_ eq "Coro") {
58 push @async, $ref;
59 } else {
60 push @attrs, $_;
61 }
62 }
63 return $old ? $old->($package, $ref, @attrs) : @attrs;
64 };
65 }
66
67 sub INIT {
68 &async(pop @async) while @async;
69 }
70}
71
72=item $main
73
74This coroutine represents the main program.
75
76=cut
77
78our $main = new Coro;
79
80=item $current (or as function: current)
81
82The current coroutine (the last coroutine switched to). The initial value is C<$main> (of course).
83
84=cut
85
86# maybe some other module used Coro::Specific before...
87if ($current) {
88 $main->{specific} = $current->{specific};
89}
90
91our $current = $main;
92
93sub current() { $current }
94
95=item $idle
96
97The coroutine to switch to when no other coroutine is running. The default
98implementation prints "FATAL: deadlock detected" and exits.
99
100=cut
101
102# should be done using priorities :(
103our $idle = new Coro sub {
104 print STDERR "FATAL: deadlock detected\n";
105 exit(51);
106};
107
108# this coroutine is necessary because a coroutine
109# cannot destroy itself.
110my @destroy;
111my $manager = new Coro sub {
112 while() {
113 delete ((pop @destroy)->{_coro_state}) while @destroy;
114 &schedule;
115 }
116};
117
118# we really need priorities...
119my @ready; # the ready queue. hehe, rather broken ;)
120
121# static methods. not really.
122
123=head2 STATIC METHODS
124
125Static methods are actually functions that operate on the current process only.
34 126
35=over 4 127=over 4
36 128
37=cut 129=item async { ... } [@args...]
38 130
39package Coro; 131Create a new asynchronous process and return it's process object
132(usually unused). When the sub returns the new process is automatically
133terminated.
40 134
41BEGIN { 135 # create a new coroutine that just prints its arguments
42 $VERSION = 0.03; 136 async {
137 print "@_\n";
138 } 1,2,3,4;
43 139
44 require XSLoader; 140The coderef you submit MUST NOT be a closure that refers to variables
45 XSLoader::load Coro, $VERSION; 141in an outer scope. This does NOT work. Pass arguments into it instead.
46}
47 142
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 143=cut
144
145sub async(&@) {
146 my $pid = new Coro @_;
147 $manager->ready; # this ensures that the stack is cloned from the manager
148 $pid->ready;
149 $pid;
150}
151
152=item schedule
153
154Calls the scheduler. Please note that the current process will not be put
155into the ready queue, so calling this function usually means you will
156never be called again.
157
158=cut
159
160my $prev;
161
162sub schedule {
163 # should be done using priorities :(
164 ($prev, $current) = ($current, shift @ready || $idle);
165 Coro::State::transfer($prev, $current);
166}
167
168=item cede
169
170"Cede" to other processes. This function puts the current process into the
171ready queue and calls C<schedule>, which has the effect of giving up the
172current "timeslice" to other coroutines of the same or higher priority.
173
174=cut
175
176sub cede {
177 $current->ready;
178 &schedule;
179}
180
181=item terminate
182
183Terminates the current process.
184
185Future versions of this function will allow result arguments.
186
187=cut
188
189sub terminate {
190 push @destroy, $current;
191 $manager->ready;
192 &schedule;
193 # NORETURN
194}
195
196=back
197
198# dynamic methods
199
200=head2 PROCESS METHODS
201
202These are the methods you can call on process objects.
203
204=over 4
205
206=item new Coro \&sub [, @args...]
207
208Create a new process and return it. When the sub returns the process
209automatically terminates. To start the process you must first put it into
210the ready queue by calling the ready method.
211
212The coderef you submit MUST NOT be a closure that refers to variables
213in an outer scope. This does NOT work. Pass arguments into it instead.
214
215=cut
216
217sub _newcoro {
218 terminate &{+shift};
219}
59 220
60sub new { 221sub new {
61 my $class = $_[0]; 222 my $class = shift;
62 my $proc = $_[1] || sub { die "tried to transfer to an empty coroutine" }; 223 bless {
63 bless _newprocess { 224 _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; 225 }, $class;
73} 226}
74 227
75=item $prev->transfer($next) 228=item $process->ready
76 229
77Save the state of the current subroutine in C<$prev> and switch to the 230Put the current process into the ready queue.
78coroutine saved in C<$next>.
79 231
80The "state" of a subroutine only ever includes scope, i.e. lexical
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
88The easiest way to do this is to create your own scheduling primitive like this:
89
90 sub schedule {
91 local ($_, $@, ...);
92 $old->transfer($new);
93 }
94
95=cut 232=cut
96 233
97# I call the _transfer function from a perl function 234sub ready {
98# because that way perl saves all important things on 235 push @ready, $_[0];
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} 236}
104 237
105=item $error, $error_msg, $error_coro 238=back
106 239
107This coroutine will be called on fatal errors. C<$error_msg> and
108C<$error_coro> return the error message and the error-causing coroutine
109(NOT an object) respectively. This API might change.
110
111=cut 240=cut
112
113$error_msg =
114$error_coro = undef;
115
116$error = _newprocess {
117 print STDERR "FATAL: $error_msg\nprogram aborted\n";
118 exit 50;
119};
120 241
1211; 2421;
122 243
123=back 244=head1 BUGS/LIMITATIONS
124 245
125=head1 BUGS 246 - could be faster, especially when the core would introduce special
126 247 support for coroutines (like it does for threads).
127This module has not yet been extensively tested. 248 - there is still a memleak on coroutine termination that I could not
249 identify. Could be as small as a single SV.
250 - this module is not well-tested.
251 - if variables or arguments "disappear" (become undef) or become
252 corrupted please contact the author so he cen iron out the
253 remaining bugs.
254 - this module is not thread-safe. You must only ever use this module from
255 the same thread (this requirement might be loosened in the future to
256 allow per-thread schedulers, but Coro::State does not yet allow this).
128 257
129=head1 SEE ALSO 258=head1 SEE ALSO
130 259
131L<Coro::Process>, L<Coro::Signal>. 260L<Coro::Channel>, L<Coro::Cont>, L<Coro::Specific>, L<Coro::Semaphore>,
261L<Coro::Signal>, L<Coro::State>, L<Coro::Event>, L<Coro::RWLock>,
262L<Coro::L<Coro::Handle>, L<Coro::Socket>.
132 263
133=head1 AUTHOR 264=head1 AUTHOR
134 265
135 Marc Lehmann <pcg@goof.com> 266 Marc Lehmann <pcg@goof.com>
136 http://www.goof.com/pcg/marc/ 267 http://www.goof.com/pcg/marc/

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines