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

Comparing cvsroot/Coro/Coro.pm (file contents):
Revision 1.181 by root, Fri May 9 22:04:37 2008 UTC vs.
Revision 1.221 by root, Tue Nov 18 05:51:38 2008 UTC

16 cede; # yield to coroutine 16 cede; # yield to coroutine
17 print "3\n"; 17 print "3\n";
18 cede; # and again 18 cede; # and again
19 19
20 # use locking 20 # use locking
21 use Coro::Semaphore;
21 my $lock = new Coro::Semaphore; 22 my $lock = new Coro::Semaphore;
22 my $locked; 23 my $locked;
23 24
24 $lock->down; 25 $lock->down;
25 $locked = 1; 26 $locked = 1;
35parallel access are rarely an issue, making coroutine programming much 36parallel access are rarely an issue, making coroutine programming much
36safer and easier than threads programming. 37safer and easier than threads programming.
37 38
38Unlike a normal perl program, however, coroutines allow you to have 39Unlike a normal perl program, however, coroutines allow you to have
39multiple running interpreters that share data, which is especially useful 40multiple running interpreters that share data, which is especially useful
40to code pseudo-parallel processes, such as multiple HTTP-GET requests 41to code pseudo-parallel processes and for event-based programming, such as
41running concurrently. 42multiple HTTP-GET requests running concurrently. See L<Coro::AnyEvent> to
43learn more.
42 44
43Coroutines are also useful because Perl has no support for threads (the so 45Coroutines are also useful because Perl has no support for threads (the so
44called "threads" that perl offers are nothing more than the (bad) process 46called "threads" that perl offers are nothing more than the (bad) process
45emulation coming from the Windows platform: On standard operating systems 47emulation coming from the Windows platform: On standard operating systems
46they serve no purpose whatsoever, except by making your programs slow and 48they serve no purpose whatsoever, except by making your programs slow and
54 56
55=cut 57=cut
56 58
57package Coro; 59package Coro;
58 60
59use strict; 61use strict qw(vars subs);
60no warnings "uninitialized"; 62no warnings "uninitialized";
61 63
62use Coro::State; 64use Coro::State;
63 65
64use base qw(Coro::State Exporter); 66use base qw(Coro::State Exporter);
65 67
66our $idle; # idle handler 68our $idle; # idle handler
67our $main; # main coroutine 69our $main; # main coroutine
68our $current; # current coroutine 70our $current; # current coroutine
69 71
70our $VERSION = 4.6; 72our $VERSION = 5.0;
71 73
72our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub); 74our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub);
73our %EXPORT_TAGS = ( 75our %EXPORT_TAGS = (
74 prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)], 76 prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)],
75); 77);
80=item $Coro::main 82=item $Coro::main
81 83
82This variable stores the coroutine object that represents the main 84This variable stores the coroutine object that represents the main
83program. While you cna C<ready> it and do most other things you can do to 85program. While you cna C<ready> it and do most other things you can do to
84coroutines, it is mainly useful to compare again C<$Coro::current>, to see 86coroutines, it is mainly useful to compare again C<$Coro::current>, to see
85wether you are running in the main program or not. 87whether you are running in the main program or not.
86 88
87=cut 89=cut
88 90
89$main = new Coro; 91# $main is now being initialised by Coro::State
90 92
91=item $Coro::current 93=item $Coro::current
92 94
93The coroutine object representing the current coroutine (the last 95The coroutine object representing the current coroutine (the last
94coroutine that the Coro scheduler switched to). The initial value is 96coroutine that the Coro scheduler switched to). The initial value is
95C<$main> (of course). 97C<$Coro::main> (of course).
96 98
97This variable is B<strictly> I<read-only>. You can take copies of the 99This variable is B<strictly> I<read-only>. You can take copies of the
98value stored in it and use it as any other coroutine object, but you must 100value stored in it and use it as any other coroutine object, but you must
99not otherwise modify the variable itself. 101not otherwise modify the variable itself.
100 102
101=cut 103=cut
102
103$main->{desc} = "[main::]";
104
105# maybe some other module used Coro::Specific before...
106$main->{_specific} = $current->{_specific}
107 if $current;
108
109_set_current $main;
110 104
111sub current() { $current } # [DEPRECATED] 105sub current() { $current } # [DEPRECATED]
112 106
113=item $Coro::idle 107=item $Coro::idle
114 108
150 $self->_destroy 144 $self->_destroy
151 or return; 145 or return;
152 146
153 # call all destruction callbacks 147 # call all destruction callbacks
154 $_->(@{$self->{_status}}) 148 $_->(@{$self->{_status}})
155 for @{(delete $self->{_on_destroy}) || []}; 149 for @{ delete $self->{_on_destroy} || [] };
156} 150}
157 151
158# this coroutine is necessary because a coroutine 152# this coroutine is necessary because a coroutine
159# cannot destroy itself. 153# cannot destroy itself.
160my @destroy; 154my @destroy;
166 while @destroy; 160 while @destroy;
167 161
168 &schedule; 162 &schedule;
169 } 163 }
170}; 164};
171$manager->desc ("[coro manager]"); 165$manager->{desc} = "[coro manager]";
172$manager->prio (PRIO_MAX); 166$manager->prio (PRIO_MAX);
173 167
174=back 168=back
175 169
176=head2 SIMPLE COROUTINE CREATION 170=head2 SIMPLE COROUTINE CREATION
219terminate or join on it (although you are allowed to), and you get a 213terminate or join on it (although you are allowed to), and you get a
220coroutine that might have executed other code already (which can be good 214coroutine that might have executed other code already (which can be good
221or bad :). 215or bad :).
222 216
223On the plus side, this function is faster than creating (and destroying) 217On the plus side, this function is faster than creating (and destroying)
224a completely new coroutine, so if you need a lot of generic coroutines in 218a completly new coroutine, so if you need a lot of generic coroutines in
225quick successsion, use C<async_pool>, not C<async>. 219quick successsion, use C<async_pool>, not C<async>.
226 220
227The code block is executed in an C<eval> context and a warning will be 221The code block is executed in an C<eval> context and a warning will be
228issued in case of an exception instead of terminating the program, as 222issued in case of an exception instead of terminating the program, as
229C<async> does. As the coroutine is being reused, stuff like C<on_destroy> 223C<async> does. As the coroutine is being reused, stuff like C<on_destroy>
233 227
234The priority will be reset to C<0> after each run, tracing will be 228The priority will be reset to C<0> after each run, tracing will be
235disabled, the description will be reset and the default output filehandle 229disabled, the description will be reset and the default output filehandle
236gets restored, so you can change all these. Otherwise the coroutine will 230gets restored, so you can change all these. Otherwise the coroutine will
237be re-used "as-is": most notably if you change other per-coroutine global 231be re-used "as-is": most notably if you change other per-coroutine global
238stuff such as C<$/> you I<must needs> to revert that change, which is most 232stuff such as C<$/> you I<must needs> revert that change, which is most
239simply done by using local as in: C< local $/ >. 233simply done by using local as in: C<< local $/ >>.
240 234
241The pool size is limited to C<8> idle coroutines (this can be adjusted by 235The idle pool size is limited to C<8> idle coroutines (this can be
242changing $Coro::POOL_SIZE), and there can be as many non-idle coros as 236adjusted by changing $Coro::POOL_SIZE), but there can be as many non-idle
243required. 237coros as required.
244 238
245If you are concerned about pooled coroutines growing a lot because a 239If you are concerned about pooled coroutines growing a lot because a
246single C<async_pool> used a lot of stackspace you can e.g. C<async_pool 240single C<async_pool> used a lot of stackspace you can e.g. C<async_pool
247{ terminate }> once per second or so to slowly replenish the pool. In 241{ terminate }> once per second or so to slowly replenish the pool. In
248addition to that, when the stacks used by a handler grows larger than 16kb 242addition to that, when the stacks used by a handler grows larger than 16kb
265 _pool_2 $cb; 259 _pool_2 $cb;
266 &schedule; 260 &schedule;
267 } 261 }
268 }; 262 };
269 263
264 if ($@) {
270 last if $@ eq "\3async_pool terminate\2\n"; 265 last if $@ eq "\3async_pool terminate\2\n";
271 warn $@ if $@; 266 warn $@;
267 }
272 } 268 }
273} 269}
274 270
275sub async_pool(&@) { 271sub async_pool(&@) {
276 # this is also inlined into the unlock_scheduler 272 # this is also inlined into the unblock_scheduler
277 my $coro = (pop @async_pool) || new Coro \&pool_handler; 273 my $coro = (pop @async_pool) || new Coro \&pool_handler;
278 274
279 $coro->{_invoke} = [@_]; 275 $coro->{_invoke} = [@_];
280 $coro->ready; 276 $coro->ready;
281 277
306This makes C<schedule> I<the> generic method to use to block the current 302This makes C<schedule> I<the> generic method to use to block the current
307coroutine and wait for events: first you remember the current coroutine in 303coroutine and wait for events: first you remember the current coroutine in
308a variable, then arrange for some callback of yours to call C<< ->ready 304a variable, then arrange for some callback of yours to call C<< ->ready
309>> on that once some event happens, and last you call C<schedule> to put 305>> on that once some event happens, and last you call C<schedule> to put
310yourself to sleep. Note that a lot of things can wake your coroutine up, 306yourself to sleep. Note that a lot of things can wake your coroutine up,
311so you need to check wether the event indeed happened, e.g. by storing the 307so you need to check whether the event indeed happened, e.g. by storing the
312status in a variable. 308status in a variable.
313 309
314The canonical way to wait on external events is this: 310The canonical way to wait on external events is this:
315 311
316 { 312 {
355Kills/terminates/cancels all coroutines except the currently running 351Kills/terminates/cancels all coroutines except the currently running
356one. This is useful after a fork, either in the child or the parent, as 352one. This is useful after a fork, either in the child or the parent, as
357usually only one of them should inherit the running coroutines. 353usually only one of them should inherit the running coroutines.
358 354
359Note that while this will try to free some of the main programs resources, 355Note that while this will try to free some of the main programs resources,
360you cnanot free all of them, so if a coroutine that is not the main 356you cannot free all of them, so if a coroutine that is not the main
361program calls this function, there will be some one-time resource leak. 357program calls this function, there will be some one-time resource leak.
362 358
363=cut 359=cut
364 360
365sub terminate { 361sub terminate {
414once all the coroutines of higher priority and all coroutines of the same 410once all the coroutines of higher priority and all coroutines of the same
415priority that were put into the ready queue earlier have been resumed. 411priority that were put into the ready queue earlier have been resumed.
416 412
417=item $is_ready = $coroutine->is_ready 413=item $is_ready = $coroutine->is_ready
418 414
419Return wether the coroutine is currently the ready queue or not, 415Return whether the coroutine is currently the ready queue or not,
420 416
421=item $coroutine->cancel (arg...) 417=item $coroutine->cancel (arg...)
422 418
423Terminates the given coroutine and makes it return the given arguments as 419Terminates the given coroutine and makes it return the given arguments as
424status (default: the empty list). Never returns if the coroutine is the 420status (default: the empty list). Never returns if the coroutine is the
437 } else { 433 } else {
438 $self->_cancel; 434 $self->_cancel;
439 } 435 }
440} 436}
441 437
438=item $coroutine->throw ([$scalar])
439
440If C<$throw> is specified and defined, it will be thrown as an exception
441inside the coroutine at the next convenient point in time (usually after
442it gains control at the next schedule/transfer/cede). Otherwise clears the
443exception object.
444
445The exception object will be thrown "as is" with the specified scalar in
446C<$@>, i.e. if it is a string, no line number or newline will be appended
447(unlike with C<die>).
448
449This can be used as a softer means than C<cancel> to ask a coroutine to
450end itself, although there is no guarantee that the exception will lead to
451termination, and if the exception isn't caught it might well end the whole
452program.
453
454You might also think of C<throw> as being the moral equivalent of
455C<kill>ing a coroutine with a signal (in this case, a scalar).
456
442=item $coroutine->join 457=item $coroutine->join
443 458
444Wait until the coroutine terminates and return any values given to the 459Wait until the coroutine terminates and return any values given to the
445C<terminate> or C<cancel> functions. C<join> can be called concurrently 460C<terminate> or C<cancel> functions. C<join> can be called concurrently
446from multiple coroutines, and all will be resumed and given the status 461from multiple coroutines, and all will be resumed and given the status
507higher values mean lower priority, just as in unix). 522higher values mean lower priority, just as in unix).
508 523
509=item $olddesc = $coroutine->desc ($newdesc) 524=item $olddesc = $coroutine->desc ($newdesc)
510 525
511Sets (or gets in case the argument is missing) the description for this 526Sets (or gets in case the argument is missing) the description for this
512coroutine. This is just a free-form string you can associate with a coroutine. 527coroutine. This is just a free-form string you can associate with a
528coroutine.
513 529
514This method simply sets the C<< $coroutine->{desc} >> member to the given string. You 530This method simply sets the C<< $coroutine->{desc} >> member to the given
515can modify this member directly if you wish. 531string. You can modify this member directly if you wish.
516
517=item $coroutine->throw ([$scalar])
518
519If C<$throw> is specified and defined, it will be thrown as an exception
520inside the coroutine at the next convinient point in time (usually after
521it gains control at the next schedule/transfer/cede). Otherwise clears the
522exception object.
523
524The exception object will be thrown "as is" with the specified scalar in
525C<$@>, i.e. if it is a string, no line number or newline will be appended
526(unlike with C<die>).
527
528This can be used as a softer means than C<cancel> to ask a coroutine to
529end itself, although there is no guarentee that the exception will lead to
530termination, and if the exception isn't caught it might well end the whole
531program.
532 532
533=cut 533=cut
534 534
535sub desc { 535sub desc {
536 my $old = $_[0]{desc}; 536 my $old = $_[0]{desc};
610creating event callbacks that want to block. 610creating event callbacks that want to block.
611 611
612If your handler does not plan to block (e.g. simply sends a message to 612If your handler does not plan to block (e.g. simply sends a message to
613another coroutine, or puts some other coroutine into the ready queue), 613another coroutine, or puts some other coroutine into the ready queue),
614there is no reason to use C<unblock_sub>. 614there is no reason to use C<unblock_sub>.
615
616Note that you also need to use C<unblock_sub> for any other callbacks that
617are indirectly executed by any C-based event loop. For example, when you
618use a module that uses L<AnyEvent> (and you use L<Coro::AnyEvent>) and it
619provides callbacks that are the result of some event callback, then you
620must not block either, or use C<unblock_sub>.
615 621
616=cut 622=cut
617 623
618our @unblock_queue; 624our @unblock_queue;
619 625
632 cede; # for short-lived callbacks, this reduces pressure on the coro pool 638 cede; # for short-lived callbacks, this reduces pressure on the coro pool
633 } 639 }
634 schedule; # sleep well 640 schedule; # sleep well
635 } 641 }
636}; 642};
637$unblock_scheduler->desc ("[unblock_sub scheduler]"); 643$unblock_scheduler->{desc} = "[unblock_sub scheduler]";
638 644
639sub unblock_sub(&) { 645sub unblock_sub(&) {
640 my $cb = shift; 646 my $cb = shift;
641 647
642 sub { 648 sub {
651 657
6521; 6581;
653 659
654=head1 BUGS/LIMITATIONS 660=head1 BUGS/LIMITATIONS
655 661
662=over 4
663
664=item fork with pthread backend
665
666When Coro is compiled using the pthread backend (which isn't recommended
667but required on many BSDs as their libcs are completely broken), then
668coroutines will not survive a fork. There is no known workaround except to
669fix your libc and use a saner backend.
670
671=item perl process emulation ("threads")
672
656This module is not perl-pseudo-thread-safe. You should only ever use this 673This module is not perl-pseudo-thread-safe. You should only ever use this
657module from the same thread (this requirement might be removed in the 674module from the same thread (this requirement might be removed in the
658future to allow per-thread schedulers, but Coro::State does not yet allow 675future to allow per-thread schedulers, but Coro::State does not yet allow
659this). I recommend disabling thread support and using processes, as this 676this). I recommend disabling thread support and using processes, as having
660is much faster and uses less memory. 677the windows process emulation enabled under unix roughly halves perl
678performance, even when not used.
679
680=item coroutine switching not signal safe
681
682You must not switch to another coroutine from within a signal handler
683(only relevant with %SIG - most event libraries provide safe signals).
684
685That means you I<MUST NOT> call any function that might "block" the
686current coroutine - C<cede>, C<schedule> C<< Coro::Semaphore->down >> or
687anything that calls those. Everything else, including calling C<ready>,
688works.
689
690=back
691
661 692
662=head1 SEE ALSO 693=head1 SEE ALSO
663 694
664Event-Loop integration: L<Coro::AnyEvent>, L<Coro::EV>, L<Coro::Event>. 695Event-Loop integration: L<Coro::AnyEvent>, L<Coro::EV>, L<Coro::Event>.
665 696

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines