ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/Coro/Coro.pm
Revision: 1.212
Committed: Mon Nov 10 04:37:23 2008 UTC (15 years, 6 months ago) by root
Branch: MAIN
CVS Tags: rel-4_91
Changes since 1.211: +1 -1 lines
Log Message:
4.91

File Contents

# Content
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 print "2\n";
12 cede; # yield back to main
13 print "4\n";
14 };
15 print "1\n";
16 cede; # yield to coroutine
17 print "3\n";
18 cede; # and again
19
20 # use locking
21 use Coro::Semaphore;
22 my $lock = new Coro::Semaphore;
23 my $locked;
24
25 $lock->down;
26 $locked = 1;
27 $lock->up;
28
29 =head1 DESCRIPTION
30
31 This module collection manages coroutines. Coroutines are similar to
32 threads but don't (in general) run in parallel at the same time even
33 on SMP machines. The specific flavor of coroutine used in this module
34 also guarantees you that it will not switch between coroutines unless
35 necessary, at easily-identified points in your program, so locking and
36 parallel access are rarely an issue, making coroutine programming much
37 safer and easier than threads programming.
38
39 Unlike a normal perl program, however, coroutines allow you to have
40 multiple running interpreters that share data, which is especially useful
41 to code pseudo-parallel processes and for event-based programming, such as
42 multiple HTTP-GET requests running concurrently. See L<Coro::AnyEvent> to
43 learn more.
44
45 Coroutines are also useful because Perl has no support for threads (the so
46 called "threads" that perl offers are nothing more than the (bad) process
47 emulation coming from the Windows platform: On standard operating systems
48 they serve no purpose whatsoever, except by making your programs slow and
49 making them use a lot of memory. Best disable them when building perl, or
50 aks your software vendor/distributor to do it for you).
51
52 In this module, coroutines are defined as "callchain + lexical variables +
53 @_ + $_ + $@ + $/ + C stack), that is, a coroutine has its own callchain,
54 its own set of lexicals and its own set of perls most important global
55 variables (see L<Coro::State> for more configuration).
56
57 =cut
58
59 package Coro;
60
61 use strict qw(vars subs);
62 no warnings "uninitialized";
63
64 use Coro::State;
65
66 use base qw(Coro::State Exporter);
67
68 our $idle; # idle handler
69 our $main; # main coroutine
70 our $current; # current coroutine
71
72 our $VERSION = 4.91;
73
74 our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub);
75 our %EXPORT_TAGS = (
76 prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)],
77 );
78 our @EXPORT_OK = (@{$EXPORT_TAGS{prio}}, qw(nready));
79
80 =over 4
81
82 =item $Coro::main
83
84 This variable stores the coroutine object that represents the main
85 program. While you cna C<ready> it and do most other things you can do to
86 coroutines, it is mainly useful to compare again C<$Coro::current>, to see
87 whether you are running in the main program or not.
88
89 =cut
90
91 $main = new Coro;
92
93 =item $Coro::current
94
95 The coroutine object representing the current coroutine (the last
96 coroutine that the Coro scheduler switched to). The initial value is
97 C<$main> (of course).
98
99 This variable is B<strictly> I<read-only>. You can take copies of the
100 value stored in it and use it as any other coroutine object, but you must
101 not otherwise modify the variable itself.
102
103 =cut
104
105 $main->{desc} = "[main::]";
106
107 # maybe some other module used Coro::Specific before...
108 $main->{_specific} = $current->{_specific}
109 if $current;
110
111 _set_current $main;
112
113 sub current() { $current } # [DEPRECATED]
114
115 =item $Coro::idle
116
117 This variable is mainly useful to integrate Coro into event loops. It is
118 usually better to rely on L<Coro::AnyEvent> or LC<Coro::EV>, as this is
119 pretty low-level functionality.
120
121 This variable stores a callback that is called whenever the scheduler
122 finds no ready coroutines to run. The default implementation prints
123 "FATAL: deadlock detected" and exits, because the program has no other way
124 to continue.
125
126 This hook is overwritten by modules such as C<Coro::Timer> and
127 C<Coro::AnyEvent> to wait on an external event that hopefully wake up a
128 coroutine so the scheduler can run it.
129
130 Note that the callback I<must not>, under any circumstances, block
131 the current coroutine. Normally, this is achieved by having an "idle
132 coroutine" that calls the event loop and then blocks again, and then
133 readying that coroutine in the idle handler.
134
135 See L<Coro::Event> or L<Coro::AnyEvent> for examples of using this
136 technique.
137
138 Please note that if your callback recursively invokes perl (e.g. for event
139 handlers), then it must be prepared to be called recursively itself.
140
141 =cut
142
143 $idle = sub {
144 require Carp;
145 Carp::croak ("FATAL: deadlock detected");
146 };
147
148 sub _cancel {
149 my ($self) = @_;
150
151 # free coroutine data and mark as destructed
152 $self->_destroy
153 or return;
154
155 # call all destruction callbacks
156 $_->(@{$self->{_status}})
157 for @{ delete $self->{_on_destroy} || [] };
158 }
159
160 # this coroutine is necessary because a coroutine
161 # cannot destroy itself.
162 my @destroy;
163 my $manager;
164
165 $manager = new Coro sub {
166 while () {
167 (shift @destroy)->_cancel
168 while @destroy;
169
170 &schedule;
171 }
172 };
173 $manager->{desc} = "[coro manager]";
174 $manager->prio (PRIO_MAX);
175
176 =back
177
178 =head2 SIMPLE COROUTINE CREATION
179
180 =over 4
181
182 =item async { ... } [@args...]
183
184 Create a new coroutine and return it's coroutine object (usually
185 unused). The coroutine will be put into the ready queue, so
186 it will start running automatically on the next scheduler run.
187
188 The first argument is a codeblock/closure that should be executed in the
189 coroutine. When it returns argument returns the coroutine is automatically
190 terminated.
191
192 The remaining arguments are passed as arguments to the closure.
193
194 See the C<Coro::State::new> constructor for info about the coroutine
195 environment in which coroutines are executed.
196
197 Calling C<exit> in a coroutine will do the same as calling exit outside
198 the coroutine. Likewise, when the coroutine dies, the program will exit,
199 just as it would in the main program.
200
201 If you do not want that, you can provide a default C<die> handler, or
202 simply avoid dieing (by use of C<eval>).
203
204 Example: Create a new coroutine that just prints its arguments.
205
206 async {
207 print "@_\n";
208 } 1,2,3,4;
209
210 =cut
211
212 sub async(&@) {
213 my $coro = new Coro @_;
214 $coro->ready;
215 $coro
216 }
217
218 =item async_pool { ... } [@args...]
219
220 Similar to C<async>, but uses a coroutine pool, so you should not call
221 terminate or join on it (although you are allowed to), and you get a
222 coroutine that might have executed other code already (which can be good
223 or bad :).
224
225 On the plus side, this function is faster than creating (and destroying)
226 a completly new coroutine, so if you need a lot of generic coroutines in
227 quick successsion, use C<async_pool>, not C<async>.
228
229 The code block is executed in an C<eval> context and a warning will be
230 issued in case of an exception instead of terminating the program, as
231 C<async> does. As the coroutine is being reused, stuff like C<on_destroy>
232 will not work in the expected way, unless you call terminate or cancel,
233 which somehow defeats the purpose of pooling (but is fine in the
234 exceptional case).
235
236 The priority will be reset to C<0> after each run, tracing will be
237 disabled, the description will be reset and the default output filehandle
238 gets restored, so you can change all these. Otherwise the coroutine will
239 be re-used "as-is": most notably if you change other per-coroutine global
240 stuff such as C<$/> you I<must needs> revert that change, which is most
241 simply done by using local as in: C<< local $/ >>.
242
243 The idle pool size is limited to C<8> idle coroutines (this can be
244 adjusted by changing $Coro::POOL_SIZE), but there can be as many non-idle
245 coros as required.
246
247 If you are concerned about pooled coroutines growing a lot because a
248 single C<async_pool> used a lot of stackspace you can e.g. C<async_pool
249 { terminate }> once per second or so to slowly replenish the pool. In
250 addition to that, when the stacks used by a handler grows larger than 16kb
251 (adjustable via $Coro::POOL_RSS) it will also be destroyed.
252
253 =cut
254
255 our $POOL_SIZE = 8;
256 our $POOL_RSS = 16 * 1024;
257 our @async_pool;
258
259 sub pool_handler {
260 my $cb;
261
262 while () {
263 eval {
264 while () {
265 _pool_1 $cb;
266 &$cb;
267 _pool_2 $cb;
268 &schedule;
269 }
270 };
271
272 if ($@) {
273 last if $@ eq "\3async_pool terminate\2\n";
274 warn $@;
275 }
276 }
277 }
278
279 sub async_pool(&@) {
280 # this is also inlined into the unlock_scheduler
281 my $coro = (pop @async_pool) || new Coro \&pool_handler;
282
283 $coro->{_invoke} = [@_];
284 $coro->ready;
285
286 $coro
287 }
288
289 =back
290
291 =head2 STATIC METHODS
292
293 Static methods are actually functions that operate on the current coroutine.
294
295 =over 4
296
297 =item schedule
298
299 Calls the scheduler. The scheduler will find the next coroutine that is
300 to be run from the ready queue and switches to it. The next coroutine
301 to be run is simply the one with the highest priority that is longest
302 in its ready queue. If there is no coroutine ready, it will clal the
303 C<$Coro::idle> hook.
304
305 Please note that the current coroutine will I<not> be put into the ready
306 queue, so calling this function usually means you will never be called
307 again unless something else (e.g. an event handler) calls C<< ->ready >>,
308 thus waking you up.
309
310 This makes C<schedule> I<the> generic method to use to block the current
311 coroutine and wait for events: first you remember the current coroutine in
312 a variable, then arrange for some callback of yours to call C<< ->ready
313 >> on that once some event happens, and last you call C<schedule> to put
314 yourself to sleep. Note that a lot of things can wake your coroutine up,
315 so you need to check whether the event indeed happened, e.g. by storing the
316 status in a variable.
317
318 The canonical way to wait on external events is this:
319
320 {
321 # remember current coroutine
322 my $current = $Coro::current;
323
324 # register a hypothetical event handler
325 on_event_invoke sub {
326 # wake up sleeping coroutine
327 $current->ready;
328 undef $current;
329 };
330
331 # call schedule until event occurred.
332 # in case we are woken up for other reasons
333 # (current still defined), loop.
334 Coro::schedule while $current;
335 }
336
337 =item cede
338
339 "Cede" to other coroutines. This function puts the current coroutine into
340 the ready queue and calls C<schedule>, which has the effect of giving
341 up the current "timeslice" to other coroutines of the same or higher
342 priority. Once your coroutine gets its turn again it will automatically be
343 resumed.
344
345 This function is often called C<yield> in other languages.
346
347 =item Coro::cede_notself
348
349 Works like cede, but is not exported by default and will cede to I<any>
350 coroutine, regardless of priority. This is useful sometimes to ensure
351 progress is made.
352
353 =item terminate [arg...]
354
355 Terminates the current coroutine with the given status values (see L<cancel>).
356
357 =item killall
358
359 Kills/terminates/cancels all coroutines except the currently running
360 one. This is useful after a fork, either in the child or the parent, as
361 usually only one of them should inherit the running coroutines.
362
363 Note that while this will try to free some of the main programs resources,
364 you cannot free all of them, so if a coroutine that is not the main
365 program calls this function, there will be some one-time resource leak.
366
367 =cut
368
369 sub terminate {
370 $current->cancel (@_);
371 }
372
373 sub killall {
374 for (Coro::State::list) {
375 $_->cancel
376 if $_ != $current && UNIVERSAL::isa $_, "Coro";
377 }
378 }
379
380 =back
381
382 =head2 COROUTINE METHODS
383
384 These are the methods you can call on coroutine objects (or to create
385 them).
386
387 =over 4
388
389 =item new Coro \&sub [, @args...]
390
391 Create a new coroutine and return it. When the sub returns, the coroutine
392 automatically terminates as if C<terminate> with the returned values were
393 called. To make the coroutine run you must first put it into the ready
394 queue by calling the ready method.
395
396 See C<async> and C<Coro::State::new> for additional info about the
397 coroutine environment.
398
399 =cut
400
401 sub _run_coro {
402 terminate &{+shift};
403 }
404
405 sub new {
406 my $class = shift;
407
408 $class->SUPER::new (\&_run_coro, @_)
409 }
410
411 =item $success = $coroutine->ready
412
413 Put the given coroutine into the end of its ready queue (there is one
414 queue for each priority) and return true. If the coroutine is already in
415 the ready queue, do nothing and return false.
416
417 This ensures that the scheduler will resume this coroutine automatically
418 once all the coroutines of higher priority and all coroutines of the same
419 priority that were put into the ready queue earlier have been resumed.
420
421 =item $is_ready = $coroutine->is_ready
422
423 Return whether the coroutine is currently the ready queue or not,
424
425 =item $coroutine->cancel (arg...)
426
427 Terminates the given coroutine and makes it return the given arguments as
428 status (default: the empty list). Never returns if the coroutine is the
429 current coroutine.
430
431 =cut
432
433 sub cancel {
434 my $self = shift;
435 $self->{_status} = [@_];
436
437 if ($current == $self) {
438 push @destroy, $self;
439 $manager->ready;
440 &schedule while 1;
441 } else {
442 $self->_cancel;
443 }
444 }
445
446 =item $coroutine->throw ([$scalar])
447
448 If C<$throw> is specified and defined, it will be thrown as an exception
449 inside the coroutine at the next convenient point in time (usually after
450 it gains control at the next schedule/transfer/cede). Otherwise clears the
451 exception object.
452
453 The exception object will be thrown "as is" with the specified scalar in
454 C<$@>, i.e. if it is a string, no line number or newline will be appended
455 (unlike with C<die>).
456
457 This can be used as a softer means than C<cancel> to ask a coroutine to
458 end itself, although there is no guarantee that the exception will lead to
459 termination, and if the exception isn't caught it might well end the whole
460 program.
461
462 You might also think of C<throw> as being the moral equivalent of
463 C<kill>ing a coroutine with a signal (in this case, a scalar).
464
465 =item $coroutine->join
466
467 Wait until the coroutine terminates and return any values given to the
468 C<terminate> or C<cancel> functions. C<join> can be called concurrently
469 from multiple coroutines, and all will be resumed and given the status
470 return once the C<$coroutine> terminates.
471
472 =cut
473
474 sub join {
475 my $self = shift;
476
477 unless ($self->{_status}) {
478 my $current = $current;
479
480 push @{$self->{_on_destroy}}, sub {
481 $current->ready;
482 undef $current;
483 };
484
485 &schedule while $current;
486 }
487
488 wantarray ? @{$self->{_status}} : $self->{_status}[0];
489 }
490
491 =item $coroutine->on_destroy (\&cb)
492
493 Registers a callback that is called when this coroutine gets destroyed,
494 but before it is joined. The callback gets passed the terminate arguments,
495 if any, and I<must not> die, under any circumstances.
496
497 =cut
498
499 sub on_destroy {
500 my ($self, $cb) = @_;
501
502 push @{ $self->{_on_destroy} }, $cb;
503 }
504
505 =item $oldprio = $coroutine->prio ($newprio)
506
507 Sets (or gets, if the argument is missing) the priority of the
508 coroutine. Higher priority coroutines get run before lower priority
509 coroutines. Priorities are small signed integers (currently -4 .. +3),
510 that you can refer to using PRIO_xxx constants (use the import tag :prio
511 to get then):
512
513 PRIO_MAX > PRIO_HIGH > PRIO_NORMAL > PRIO_LOW > PRIO_IDLE > PRIO_MIN
514 3 > 1 > 0 > -1 > -3 > -4
515
516 # set priority to HIGH
517 current->prio(PRIO_HIGH);
518
519 The idle coroutine ($Coro::idle) always has a lower priority than any
520 existing coroutine.
521
522 Changing the priority of the current coroutine will take effect immediately,
523 but changing the priority of coroutines in the ready queue (but not
524 running) will only take effect after the next schedule (of that
525 coroutine). This is a bug that will be fixed in some future version.
526
527 =item $newprio = $coroutine->nice ($change)
528
529 Similar to C<prio>, but subtract the given value from the priority (i.e.
530 higher values mean lower priority, just as in unix).
531
532 =item $olddesc = $coroutine->desc ($newdesc)
533
534 Sets (or gets in case the argument is missing) the description for this
535 coroutine. This is just a free-form string you can associate with a
536 coroutine.
537
538 This method simply sets the C<< $coroutine->{desc} >> member to the given
539 string. You can modify this member directly if you wish.
540
541 =cut
542
543 sub desc {
544 my $old = $_[0]{desc};
545 $_[0]{desc} = $_[1] if @_ > 1;
546 $old;
547 }
548
549 =back
550
551 =head2 GLOBAL FUNCTIONS
552
553 =over 4
554
555 =item Coro::nready
556
557 Returns the number of coroutines that are currently in the ready state,
558 i.e. that can be switched to by calling C<schedule> directory or
559 indirectly. The value C<0> means that the only runnable coroutine is the
560 currently running one, so C<cede> would have no effect, and C<schedule>
561 would cause a deadlock unless there is an idle handler that wakes up some
562 coroutines.
563
564 =item my $guard = Coro::guard { ... }
565
566 This creates and returns a guard object. Nothing happens until the object
567 gets destroyed, in which case the codeblock given as argument will be
568 executed. This is useful to free locks or other resources in case of a
569 runtime error or when the coroutine gets canceled, as in both cases the
570 guard block will be executed. The guard object supports only one method,
571 C<< ->cancel >>, which will keep the codeblock from being executed.
572
573 Example: set some flag and clear it again when the coroutine gets canceled
574 or the function returns:
575
576 sub do_something {
577 my $guard = Coro::guard { $busy = 0 };
578 $busy = 1;
579
580 # do something that requires $busy to be true
581 }
582
583 =cut
584
585 sub guard(&) {
586 bless \(my $cb = $_[0]), "Coro::guard"
587 }
588
589 sub Coro::guard::cancel {
590 ${$_[0]} = sub { };
591 }
592
593 sub Coro::guard::DESTROY {
594 ${$_[0]}->();
595 }
596
597
598 =item unblock_sub { ... }
599
600 This utility function takes a BLOCK or code reference and "unblocks" it,
601 returning a new coderef. Unblocking means that calling the new coderef
602 will return immediately without blocking, returning nothing, while the
603 original code ref will be called (with parameters) from within another
604 coroutine.
605
606 The reason this function exists is that many event libraries (such as the
607 venerable L<Event|Event> module) are not coroutine-safe (a weaker form
608 of thread-safety). This means you must not block within event callbacks,
609 otherwise you might suffer from crashes or worse. The only event library
610 currently known that is safe to use without C<unblock_sub> is L<EV>.
611
612 This function allows your callbacks to block by executing them in another
613 coroutine where it is safe to block. One example where blocking is handy
614 is when you use the L<Coro::AIO|Coro::AIO> functions to save results to
615 disk, for example.
616
617 In short: simply use C<unblock_sub { ... }> instead of C<sub { ... }> when
618 creating event callbacks that want to block.
619
620 If your handler does not plan to block (e.g. simply sends a message to
621 another coroutine, or puts some other coroutine into the ready queue),
622 there is no reason to use C<unblock_sub>.
623
624 Note that you also need to use C<unblock_sub> for any other callbacks that
625 are indirectly executed by any C-based event loop. For example, when you
626 use a module that uses L<AnyEvent> (and you use L<Coro::AnyEvent>) and it
627 provides callbacks that are the result of some event callback, then you
628 must not block either, or use C<unblock_sub>.
629
630 =cut
631
632 our @unblock_queue;
633
634 # we create a special coro because we want to cede,
635 # to reduce pressure on the coro pool (because most callbacks
636 # return immediately and can be reused) and because we cannot cede
637 # inside an event callback.
638 our $unblock_scheduler = new Coro sub {
639 while () {
640 while (my $cb = pop @unblock_queue) {
641 # this is an inlined copy of async_pool
642 my $coro = (pop @async_pool) || new Coro \&pool_handler;
643
644 $coro->{_invoke} = $cb;
645 $coro->ready;
646 cede; # for short-lived callbacks, this reduces pressure on the coro pool
647 }
648 schedule; # sleep well
649 }
650 };
651 $unblock_scheduler->{desc} = "[unblock_sub scheduler]";
652
653 sub unblock_sub(&) {
654 my $cb = shift;
655
656 sub {
657 unshift @unblock_queue, [$cb, @_];
658 $unblock_scheduler->ready;
659 }
660 }
661
662 =back
663
664 =cut
665
666 1;
667
668 =head1 BUGS/LIMITATIONS
669
670 This module is not perl-pseudo-thread-safe. You should only ever use this
671 module from the same thread (this requirement might be removed in the
672 future to allow per-thread schedulers, but Coro::State does not yet allow
673 this). I recommend disabling thread support and using processes, as this
674 is much faster and uses less memory.
675
676 =head1 SEE ALSO
677
678 Event-Loop integration: L<Coro::AnyEvent>, L<Coro::EV>, L<Coro::Event>.
679
680 Debugging: L<Coro::Debug>.
681
682 Support/Utility: L<Coro::Specific>, L<Coro::Util>.
683
684 Locking/IPC: L<Coro::Signal>, L<Coro::Channel>, L<Coro::Semaphore>, L<Coro::SemaphoreSet>, L<Coro::RWLock>.
685
686 IO/Timers: L<Coro::Timer>, L<Coro::Handle>, L<Coro::Socket>, L<Coro::AIO>.
687
688 Compatibility: L<Coro::LWP>, L<Coro::BDB>, L<Coro::Storable>, L<Coro::Select>.
689
690 XS API: L<Coro::MakeMaker>.
691
692 Low level Configuration, Coroutine Environment: L<Coro::State>.
693
694 =head1 AUTHOR
695
696 Marc Lehmann <schmorp@schmorp.de>
697 http://home.schmorp.de/
698
699 =cut
700