ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/Coro/Coro.pm
Revision: 1.199
Committed: Tue Sep 23 00:02:20 2008 UTC (15 years, 8 months ago) by root
Branch: MAIN
CVS Tags: rel-4_747
Changes since 1.198: +1 -1 lines
Log Message:
4.747

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;
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.747;
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 completely 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> to revert that change, which is most
241 simply done by using local as in: C< local $/ >.
242
243 The pool size is limited to C<8> idle coroutines (this can be adjusted by
244 changing $Coro::POOL_SIZE), and there can be as many non-idle coros as
245 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->join
447
448 Wait until the coroutine terminates and return any values given to the
449 C<terminate> or C<cancel> functions. C<join> can be called concurrently
450 from multiple coroutines, and all will be resumed and given the status
451 return once the C<$coroutine> terminates.
452
453 =cut
454
455 sub join {
456 my $self = shift;
457
458 unless ($self->{_status}) {
459 my $current = $current;
460
461 push @{$self->{_on_destroy}}, sub {
462 $current->ready;
463 undef $current;
464 };
465
466 &schedule while $current;
467 }
468
469 wantarray ? @{$self->{_status}} : $self->{_status}[0];
470 }
471
472 =item $coroutine->on_destroy (\&cb)
473
474 Registers a callback that is called when this coroutine gets destroyed,
475 but before it is joined. The callback gets passed the terminate arguments,
476 if any, and I<must not> die, under any circumstances.
477
478 =cut
479
480 sub on_destroy {
481 my ($self, $cb) = @_;
482
483 push @{ $self->{_on_destroy} }, $cb;
484 }
485
486 =item $oldprio = $coroutine->prio ($newprio)
487
488 Sets (or gets, if the argument is missing) the priority of the
489 coroutine. Higher priority coroutines get run before lower priority
490 coroutines. Priorities are small signed integers (currently -4 .. +3),
491 that you can refer to using PRIO_xxx constants (use the import tag :prio
492 to get then):
493
494 PRIO_MAX > PRIO_HIGH > PRIO_NORMAL > PRIO_LOW > PRIO_IDLE > PRIO_MIN
495 3 > 1 > 0 > -1 > -3 > -4
496
497 # set priority to HIGH
498 current->prio(PRIO_HIGH);
499
500 The idle coroutine ($Coro::idle) always has a lower priority than any
501 existing coroutine.
502
503 Changing the priority of the current coroutine will take effect immediately,
504 but changing the priority of coroutines in the ready queue (but not
505 running) will only take effect after the next schedule (of that
506 coroutine). This is a bug that will be fixed in some future version.
507
508 =item $newprio = $coroutine->nice ($change)
509
510 Similar to C<prio>, but subtract the given value from the priority (i.e.
511 higher values mean lower priority, just as in unix).
512
513 =item $olddesc = $coroutine->desc ($newdesc)
514
515 Sets (or gets in case the argument is missing) the description for this
516 coroutine. This is just a free-form string you can associate with a coroutine.
517
518 This method simply sets the C<< $coroutine->{desc} >> member to the given string. You
519 can modify this member directly if you wish.
520
521 =item $coroutine->throw ([$scalar])
522
523 If C<$throw> is specified and defined, it will be thrown as an exception
524 inside the coroutine at the next convinient point in time (usually after
525 it gains control at the next schedule/transfer/cede). Otherwise clears the
526 exception object.
527
528 The exception object will be thrown "as is" with the specified scalar in
529 C<$@>, i.e. if it is a string, no line number or newline will be appended
530 (unlike with C<die>).
531
532 This can be used as a softer means than C<cancel> to ask a coroutine to
533 end itself, although there is no guarentee that the exception will lead to
534 termination, and if the exception isn't caught it might well end the whole
535 program.
536
537 =cut
538
539 sub desc {
540 my $old = $_[0]{desc};
541 $_[0]{desc} = $_[1] if @_ > 1;
542 $old;
543 }
544
545 =back
546
547 =head2 GLOBAL FUNCTIONS
548
549 =over 4
550
551 =item Coro::nready
552
553 Returns the number of coroutines that are currently in the ready state,
554 i.e. that can be switched to by calling C<schedule> directory or
555 indirectly. The value C<0> means that the only runnable coroutine is the
556 currently running one, so C<cede> would have no effect, and C<schedule>
557 would cause a deadlock unless there is an idle handler that wakes up some
558 coroutines.
559
560 =item my $guard = Coro::guard { ... }
561
562 This creates and returns a guard object. Nothing happens until the object
563 gets destroyed, in which case the codeblock given as argument will be
564 executed. This is useful to free locks or other resources in case of a
565 runtime error or when the coroutine gets canceled, as in both cases the
566 guard block will be executed. The guard object supports only one method,
567 C<< ->cancel >>, which will keep the codeblock from being executed.
568
569 Example: set some flag and clear it again when the coroutine gets canceled
570 or the function returns:
571
572 sub do_something {
573 my $guard = Coro::guard { $busy = 0 };
574 $busy = 1;
575
576 # do something that requires $busy to be true
577 }
578
579 =cut
580
581 sub guard(&) {
582 bless \(my $cb = $_[0]), "Coro::guard"
583 }
584
585 sub Coro::guard::cancel {
586 ${$_[0]} = sub { };
587 }
588
589 sub Coro::guard::DESTROY {
590 ${$_[0]}->();
591 }
592
593
594 =item unblock_sub { ... }
595
596 This utility function takes a BLOCK or code reference and "unblocks" it,
597 returning a new coderef. Unblocking means that calling the new coderef
598 will return immediately without blocking, returning nothing, while the
599 original code ref will be called (with parameters) from within another
600 coroutine.
601
602 The reason this function exists is that many event libraries (such as the
603 venerable L<Event|Event> module) are not coroutine-safe (a weaker form
604 of thread-safety). This means you must not block within event callbacks,
605 otherwise you might suffer from crashes or worse. The only event library
606 currently known that is safe to use without C<unblock_sub> is L<EV>.
607
608 This function allows your callbacks to block by executing them in another
609 coroutine where it is safe to block. One example where blocking is handy
610 is when you use the L<Coro::AIO|Coro::AIO> functions to save results to
611 disk, for example.
612
613 In short: simply use C<unblock_sub { ... }> instead of C<sub { ... }> when
614 creating event callbacks that want to block.
615
616 If your handler does not plan to block (e.g. simply sends a message to
617 another coroutine, or puts some other coroutine into the ready queue),
618 there is no reason to use C<unblock_sub>.
619
620 Note that you also need to use C<unblock_sub> for any other callbacks that
621 are indirectly executed by any C-based event loop. For example, when you
622 use a module that uses L<AnyEvent> (and you use L<Coro::AnyEvent>) and it
623 provides callbacks that are the result of some event callback, then you
624 must not block either, or use C<unblock_sub>.
625
626 =cut
627
628 our @unblock_queue;
629
630 # we create a special coro because we want to cede,
631 # to reduce pressure on the coro pool (because most callbacks
632 # return immediately and can be reused) and because we cannot cede
633 # inside an event callback.
634 our $unblock_scheduler = new Coro sub {
635 while () {
636 while (my $cb = pop @unblock_queue) {
637 # this is an inlined copy of async_pool
638 my $coro = (pop @async_pool) || new Coro \&pool_handler;
639
640 $coro->{_invoke} = $cb;
641 $coro->ready;
642 cede; # for short-lived callbacks, this reduces pressure on the coro pool
643 }
644 schedule; # sleep well
645 }
646 };
647 $unblock_scheduler->desc ("[unblock_sub scheduler]");
648
649 sub unblock_sub(&) {
650 my $cb = shift;
651
652 sub {
653 unshift @unblock_queue, [$cb, @_];
654 $unblock_scheduler->ready;
655 }
656 }
657
658 =back
659
660 =cut
661
662 1;
663
664 =head1 BUGS/LIMITATIONS
665
666 This module is not perl-pseudo-thread-safe. You should only ever use this
667 module from the same thread (this requirement might be removed in the
668 future to allow per-thread schedulers, but Coro::State does not yet allow
669 this). I recommend disabling thread support and using processes, as this
670 is much faster and uses less memory.
671
672 =head1 SEE ALSO
673
674 Event-Loop integration: L<Coro::AnyEvent>, L<Coro::EV>, L<Coro::Event>.
675
676 Debugging: L<Coro::Debug>.
677
678 Support/Utility: L<Coro::Specific>, L<Coro::Util>.
679
680 Locking/IPC: L<Coro::Signal>, L<Coro::Channel>, L<Coro::Semaphore>, L<Coro::SemaphoreSet>, L<Coro::RWLock>.
681
682 IO/Timers: L<Coro::Timer>, L<Coro::Handle>, L<Coro::Socket>, L<Coro::AIO>.
683
684 Compatibility: L<Coro::LWP>, L<Coro::BDB>, L<Coro::Storable>, L<Coro::Select>.
685
686 XS API: L<Coro::MakeMaker>.
687
688 Low level Configuration, Coroutine Environment: L<Coro::State>.
689
690 =head1 AUTHOR
691
692 Marc Lehmann <schmorp@schmorp.de>
693 http://home.schmorp.de/
694
695 =cut
696