ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/Coro/Coro.pm
Revision: 1.213
Committed: Tue Nov 11 03:26:58 2008 UTC (15 years, 6 months ago) by root
Branch: MAIN
CVS Tags: rel-4_901
Changes since 1.212: +1 -1 lines
Log Message:
4.901

File Contents

# User Rev Content
1 root 1.1 =head1 NAME
2    
3 root 1.8 Coro - coroutine process abstraction
4 root 1.1
5     =head1 SYNOPSIS
6    
7 root 1.179 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 root 1.197 use Coro::Semaphore;
22 root 1.179 my $lock = new Coro::Semaphore;
23     my $locked;
24    
25     $lock->down;
26     $locked = 1;
27     $lock->up;
28 root 1.2
29 root 1.1 =head1 DESCRIPTION
30    
31 root 1.181 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 root 1.98 necessary, at easily-identified points in your program, so locking and
36     parallel access are rarely an issue, making coroutine programming much
37 root 1.181 safer and easier than threads programming.
38 root 1.98
39 root 1.181 Unlike a normal perl program, however, coroutines allow you to have
40     multiple running interpreters that share data, which is especially useful
41 root 1.182 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 root 1.181
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 root 1.98
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 root 1.152 variables (see L<Coro::State> for more configuration).
56 root 1.22
57 root 1.8 =cut
58    
59     package Coro;
60    
61 root 1.211 use strict qw(vars subs);
62 root 1.71 no warnings "uninitialized";
63 root 1.36
64 root 1.8 use Coro::State;
65    
66 root 1.83 use base qw(Coro::State Exporter);
67 pcg 1.55
68 root 1.83 our $idle; # idle handler
69 root 1.71 our $main; # main coroutine
70     our $current; # current coroutine
71 root 1.8
72 root 1.213 our $VERSION = 4.901;
73 root 1.8
74 root 1.105 our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub);
75 root 1.71 our %EXPORT_TAGS = (
76 root 1.31 prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)],
77     );
78 root 1.97 our @EXPORT_OK = (@{$EXPORT_TAGS{prio}}, qw(nready));
79 root 1.8
80 root 1.43 =over 4
81    
82 root 1.181 =item $Coro::main
83 root 1.2
84 root 1.181 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 root 1.196 whether you are running in the main program or not.
88 root 1.1
89     =cut
90    
91 pcg 1.55 $main = new Coro;
92 root 1.8
93 root 1.181 =item $Coro::current
94 root 1.1
95 root 1.181 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 root 1.1
103 root 1.8 =cut
104    
105 root 1.131 $main->{desc} = "[main::]";
106    
107 root 1.8 # maybe some other module used Coro::Specific before...
108 root 1.142 $main->{_specific} = $current->{_specific}
109 root 1.93 if $current;
110 root 1.1
111 root 1.93 _set_current $main;
112 root 1.19
113 root 1.181 sub current() { $current } # [DEPRECATED]
114 root 1.9
115 root 1.181 =item $Coro::idle
116 root 1.9
117 root 1.181 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 root 1.83
126     This hook is overwritten by modules such as C<Coro::Timer> and
127 root 1.181 C<Coro::AnyEvent> to wait on an external event that hopefully wake up a
128 root 1.91 coroutine so the scheduler can run it.
129    
130 root 1.181 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 root 1.91 Please note that if your callback recursively invokes perl (e.g. for event
139 root 1.152 handlers), then it must be prepared to be called recursively itself.
140 root 1.9
141     =cut
142    
143 root 1.83 $idle = sub {
144 root 1.96 require Carp;
145     Carp::croak ("FATAL: deadlock detected");
146 root 1.9 };
147 root 1.8
148 root 1.103 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 root 1.142 $_->(@{$self->{_status}})
157 root 1.211 for @{ delete $self->{_on_destroy} || [] };
158 root 1.103 }
159    
160 root 1.24 # this coroutine is necessary because a coroutine
161     # cannot destroy itself.
162     my @destroy;
163 root 1.103 my $manager;
164    
165     $manager = new Coro sub {
166 pcg 1.57 while () {
167 root 1.103 (shift @destroy)->_cancel
168     while @destroy;
169    
170 root 1.24 &schedule;
171     }
172     };
173 root 1.208 $manager->{desc} = "[coro manager]";
174 root 1.103 $manager->prio (PRIO_MAX);
175    
176 root 1.43 =back
177 root 1.8
178 root 1.181 =head2 SIMPLE COROUTINE CREATION
179 root 1.8
180     =over 4
181    
182 root 1.13 =item async { ... } [@args...]
183 root 1.8
184 root 1.181 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 root 1.8 terminated.
191    
192 root 1.181 The remaining arguments are passed as arguments to the closure.
193    
194 root 1.145 See the C<Coro::State::new> constructor for info about the coroutine
195 root 1.181 environment in which coroutines are executed.
196 root 1.145
197 root 1.122 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 root 1.79
201 root 1.181 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 root 1.13 async {
207     print "@_\n";
208     } 1,2,3,4;
209    
210 root 1.8 =cut
211    
212 root 1.13 sub async(&@) {
213 root 1.104 my $coro = new Coro @_;
214     $coro->ready;
215     $coro
216 root 1.8 }
217 root 1.1
218 root 1.105 =item async_pool { ... } [@args...]
219    
220     Similar to C<async>, but uses a coroutine pool, so you should not call
221 root 1.181 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 root 1.203 a completly new coroutine, so if you need a lot of generic coroutines in
227 root 1.181 quick successsion, use C<async_pool>, not C<async>.
228 root 1.105
229 root 1.181 The code block is executed in an C<eval> context and a warning will be
230 root 1.108 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 root 1.181 which somehow defeats the purpose of pooling (but is fine in the
234     exceptional case).
235 root 1.105
236 root 1.181 The priority will be reset to C<0> after each run, tracing will be
237 root 1.146 disabled, the description will be reset and the default output filehandle
238 root 1.181 gets restored, so you can change all these. Otherwise the coroutine will
239 root 1.146 be re-used "as-is": most notably if you change other per-coroutine global
240 root 1.204 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 root 1.105
243 root 1.204 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 root 1.105
247     If you are concerned about pooled coroutines growing a lot because a
248 root 1.133 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 root 1.181 (adjustable via $Coro::POOL_RSS) it will also be destroyed.
252 root 1.105
253     =cut
254    
255     our $POOL_SIZE = 8;
256 root 1.134 our $POOL_RSS = 16 * 1024;
257     our @async_pool;
258 root 1.105
259     sub pool_handler {
260 root 1.134 my $cb;
261    
262 root 1.105 while () {
263 root 1.134 eval {
264     while () {
265 root 1.136 _pool_1 $cb;
266 root 1.134 &$cb;
267 root 1.136 _pool_2 $cb;
268 root 1.135 &schedule;
269 root 1.134 }
270 root 1.105 };
271 root 1.134
272 root 1.193 if ($@) {
273     last if $@ eq "\3async_pool terminate\2\n";
274     warn $@;
275     }
276 root 1.106 }
277     }
278 root 1.105
279     sub async_pool(&@) {
280     # this is also inlined into the unlock_scheduler
281 root 1.135 my $coro = (pop @async_pool) || new Coro \&pool_handler;
282 root 1.105
283     $coro->{_invoke} = [@_];
284     $coro->ready;
285    
286     $coro
287     }
288    
289 root 1.181 =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 root 1.8 =item schedule
298 root 1.6
299 root 1.181 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 root 1.196 so you need to check whether the event indeed happened, e.g. by storing the
316 root 1.181 status in a variable.
317 root 1.91
318     The canonical way to wait on external events is this:
319    
320     {
321 root 1.92 # remember current coroutine
322 root 1.91 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 root 1.124 # call schedule until event occurred.
332 root 1.91 # in case we are woken up for other reasons
333     # (current still defined), loop.
334     Coro::schedule while $current;
335     }
336 root 1.1
337 root 1.22 =item cede
338 root 1.1
339 root 1.181 "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 root 1.7
347 root 1.102 =item Coro::cede_notself
348    
349 root 1.181 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 root 1.102
353 root 1.40 =item terminate [arg...]
354 root 1.7
355 root 1.92 Terminates the current coroutine with the given status values (see L<cancel>).
356 root 1.13
357 root 1.141 =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 root 1.181 Note that while this will try to free some of the main programs resources,
364 root 1.196 you cannot free all of them, so if a coroutine that is not the main
365 root 1.181 program calls this function, there will be some one-time resource leak.
366    
367 root 1.1 =cut
368    
369 root 1.8 sub terminate {
370 pcg 1.59 $current->cancel (@_);
371 root 1.1 }
372 root 1.6
373 root 1.141 sub killall {
374     for (Coro::State::list) {
375     $_->cancel
376     if $_ != $current && UNIVERSAL::isa $_, "Coro";
377     }
378     }
379    
380 root 1.8 =back
381    
382 root 1.92 =head2 COROUTINE METHODS
383 root 1.8
384 root 1.181 These are the methods you can call on coroutine objects (or to create
385     them).
386 root 1.6
387 root 1.8 =over 4
388    
389 root 1.13 =item new Coro \&sub [, @args...]
390 root 1.8
391 root 1.181 Create a new coroutine and return it. When the sub returns, the coroutine
392 root 1.40 automatically terminates as if C<terminate> with the returned values were
393 root 1.181 called. To make the coroutine run you must first put it into the ready
394     queue by calling the ready method.
395 root 1.13
396 root 1.145 See C<async> and C<Coro::State::new> for additional info about the
397     coroutine environment.
398 root 1.89
399 root 1.6 =cut
400    
401 root 1.94 sub _run_coro {
402 root 1.13 terminate &{+shift};
403     }
404    
405 root 1.8 sub new {
406     my $class = shift;
407 root 1.83
408 root 1.94 $class->SUPER::new (\&_run_coro, @_)
409 root 1.8 }
410 root 1.6
411 root 1.92 =item $success = $coroutine->ready
412 root 1.1
413 root 1.181 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 root 1.1
421 root 1.92 =item $is_ready = $coroutine->is_ready
422 root 1.90
423 root 1.196 Return whether the coroutine is currently the ready queue or not,
424 root 1.28
425 root 1.92 =item $coroutine->cancel (arg...)
426 root 1.28
427 root 1.92 Terminates the given coroutine and makes it return the given arguments as
428 root 1.103 status (default: the empty list). Never returns if the coroutine is the
429     current coroutine.
430 root 1.28
431     =cut
432    
433     sub cancel {
434 pcg 1.59 my $self = shift;
435 root 1.142 $self->{_status} = [@_];
436 root 1.103
437     if ($current == $self) {
438     push @destroy, $self;
439     $manager->ready;
440     &schedule while 1;
441     } else {
442     $self->_cancel;
443     }
444 root 1.40 }
445    
446 root 1.208 =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 root 1.92 =item $coroutine->join
466 root 1.40
467     Wait until the coroutine terminates and return any values given to the
468 root 1.143 C<terminate> or C<cancel> functions. C<join> can be called concurrently
469 root 1.181 from multiple coroutines, and all will be resumed and given the status
470     return once the C<$coroutine> terminates.
471 root 1.40
472     =cut
473    
474     sub join {
475     my $self = shift;
476 root 1.103
477 root 1.142 unless ($self->{_status}) {
478 root 1.103 my $current = $current;
479    
480 root 1.142 push @{$self->{_on_destroy}}, sub {
481 root 1.103 $current->ready;
482     undef $current;
483     };
484    
485     &schedule while $current;
486 root 1.40 }
487 root 1.103
488 root 1.142 wantarray ? @{$self->{_status}} : $self->{_status}[0];
489 root 1.31 }
490    
491 root 1.101 =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 root 1.181 if any, and I<must not> die, under any circumstances.
496 root 1.101
497     =cut
498    
499     sub on_destroy {
500     my ($self, $cb) = @_;
501    
502 root 1.142 push @{ $self->{_on_destroy} }, $cb;
503 root 1.101 }
504    
505 root 1.92 =item $oldprio = $coroutine->prio ($newprio)
506 root 1.31
507 root 1.41 Sets (or gets, if the argument is missing) the priority of the
508 root 1.92 coroutine. Higher priority coroutines get run before lower priority
509     coroutines. Priorities are small signed integers (currently -4 .. +3),
510 root 1.41 that you can refer to using PRIO_xxx constants (use the import tag :prio
511     to get then):
512 root 1.31
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 root 1.92 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 root 1.31 running) will only take effect after the next schedule (of that
525 root 1.92 coroutine). This is a bug that will be fixed in some future version.
526 root 1.31
527 root 1.92 =item $newprio = $coroutine->nice ($change)
528 root 1.31
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 root 1.92 =item $olddesc = $coroutine->desc ($newdesc)
533 root 1.41
534     Sets (or gets in case the argument is missing) the description for this
535 root 1.208 coroutine. This is just a free-form string you can associate with a
536     coroutine.
537 root 1.150
538 root 1.208 This method simply sets the C<< $coroutine->{desc} >> member to the given
539     string. You can modify this member directly if you wish.
540 root 1.150
541 root 1.41 =cut
542    
543     sub desc {
544     my $old = $_[0]{desc};
545     $_[0]{desc} = $_[1] if @_ > 1;
546     $old;
547 root 1.8 }
548 root 1.1
549 root 1.8 =back
550 root 1.2
551 root 1.97 =head2 GLOBAL FUNCTIONS
552 root 1.92
553     =over 4
554    
555 root 1.97 =item Coro::nready
556    
557     Returns the number of coroutines that are currently in the ready state,
558 root 1.181 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 root 1.97
564 root 1.103 =item my $guard = Coro::guard { ... }
565    
566 root 1.119 This creates and returns a guard object. Nothing happens until the object
567 root 1.103 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 root 1.92 =item unblock_sub { ... }
599    
600     This utility function takes a BLOCK or code reference and "unblocks" it,
601 root 1.181 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 root 1.92
606 root 1.124 The reason this function exists is that many event libraries (such as the
607 root 1.92 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 root 1.181 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 root 1.92
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 root 1.181 disk, for example.
616 root 1.92
617     In short: simply use C<unblock_sub { ... }> instead of C<sub { ... }> when
618     creating event callbacks that want to block.
619    
620 root 1.181 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 root 1.183 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 root 1.92 =cut
631    
632     our @unblock_queue;
633    
634 root 1.105 # 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 root 1.132 our $unblock_scheduler = new Coro sub {
639 root 1.92 while () {
640     while (my $cb = pop @unblock_queue) {
641 root 1.105 # this is an inlined copy of async_pool
642 root 1.134 my $coro = (pop @async_pool) || new Coro \&pool_handler;
643 root 1.105
644     $coro->{_invoke} = $cb;
645     $coro->ready;
646     cede; # for short-lived callbacks, this reduces pressure on the coro pool
647 root 1.92 }
648 root 1.105 schedule; # sleep well
649 root 1.92 }
650     };
651 root 1.208 $unblock_scheduler->{desc} = "[unblock_sub scheduler]";
652 root 1.92
653     sub unblock_sub(&) {
654     my $cb = shift;
655    
656     sub {
657 root 1.105 unshift @unblock_queue, [$cb, @_];
658 root 1.92 $unblock_scheduler->ready;
659     }
660     }
661    
662     =back
663    
664 root 1.8 =cut
665 root 1.2
666 root 1.8 1;
667 root 1.14
668 root 1.17 =head1 BUGS/LIMITATIONS
669 root 1.14
670 root 1.181 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 root 1.9
676     =head1 SEE ALSO
677    
678 root 1.181 Event-Loop integration: L<Coro::AnyEvent>, L<Coro::EV>, L<Coro::Event>.
679 root 1.152
680     Debugging: L<Coro::Debug>.
681    
682     Support/Utility: L<Coro::Specific>, L<Coro::Util>.
683 root 1.67
684     Locking/IPC: L<Coro::Signal>, L<Coro::Channel>, L<Coro::Semaphore>, L<Coro::SemaphoreSet>, L<Coro::RWLock>.
685    
686 root 1.181 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 root 1.152
690 root 1.181 XS API: L<Coro::MakeMaker>.
691 root 1.67
692 root 1.181 Low level Configuration, Coroutine Environment: L<Coro::State>.
693 root 1.1
694     =head1 AUTHOR
695    
696 root 1.66 Marc Lehmann <schmorp@schmorp.de>
697 root 1.64 http://home.schmorp.de/
698 root 1.1
699     =cut
700