ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/Coro/Coro.pm
Revision: 1.202
Committed: Tue Sep 30 17:12:34 2008 UTC (15 years, 7 months ago) by root
Branch: MAIN
CVS Tags: rel-4_8
Changes since 1.201: +1 -1 lines
Log Message:
*** empty log message ***

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.71 use strict;
62     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.202 our $VERSION = 4.8;
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     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.132 $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     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 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.181 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 root 1.105
243 root 1.181 The pool size is limited to C<8> idle coroutines (this can be adjusted by
244 root 1.105 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 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.92 =item $coroutine->join
447 root 1.40
448     Wait until the coroutine terminates and return any values given to the
449 root 1.143 C<terminate> or C<cancel> functions. C<join> can be called concurrently
450 root 1.181 from multiple coroutines, and all will be resumed and given the status
451     return once the C<$coroutine> terminates.
452 root 1.40
453     =cut
454    
455     sub join {
456     my $self = shift;
457 root 1.103
458 root 1.142 unless ($self->{_status}) {
459 root 1.103 my $current = $current;
460    
461 root 1.142 push @{$self->{_on_destroy}}, sub {
462 root 1.103 $current->ready;
463     undef $current;
464     };
465    
466     &schedule while $current;
467 root 1.40 }
468 root 1.103
469 root 1.142 wantarray ? @{$self->{_status}} : $self->{_status}[0];
470 root 1.31 }
471    
472 root 1.101 =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 root 1.181 if any, and I<must not> die, under any circumstances.
477 root 1.101
478     =cut
479    
480     sub on_destroy {
481     my ($self, $cb) = @_;
482    
483 root 1.142 push @{ $self->{_on_destroy} }, $cb;
484 root 1.101 }
485    
486 root 1.92 =item $oldprio = $coroutine->prio ($newprio)
487 root 1.31
488 root 1.41 Sets (or gets, if the argument is missing) the priority of the
489 root 1.92 coroutine. Higher priority coroutines get run before lower priority
490     coroutines. Priorities are small signed integers (currently -4 .. +3),
491 root 1.41 that you can refer to using PRIO_xxx constants (use the import tag :prio
492     to get then):
493 root 1.31
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 root 1.92 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 root 1.31 running) will only take effect after the next schedule (of that
506 root 1.92 coroutine). This is a bug that will be fixed in some future version.
507 root 1.31
508 root 1.92 =item $newprio = $coroutine->nice ($change)
509 root 1.31
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 root 1.92 =item $olddesc = $coroutine->desc ($newdesc)
514 root 1.41
515     Sets (or gets in case the argument is missing) the description for this
516 root 1.92 coroutine. This is just a free-form string you can associate with a coroutine.
517 root 1.41
518 root 1.142 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 root 1.150 =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 root 1.41 =cut
538    
539     sub desc {
540     my $old = $_[0]{desc};
541     $_[0]{desc} = $_[1] if @_ > 1;
542     $old;
543 root 1.8 }
544 root 1.1
545 root 1.8 =back
546 root 1.2
547 root 1.97 =head2 GLOBAL FUNCTIONS
548 root 1.92
549     =over 4
550    
551 root 1.97 =item Coro::nready
552    
553     Returns the number of coroutines that are currently in the ready state,
554 root 1.181 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 root 1.97
560 root 1.103 =item my $guard = Coro::guard { ... }
561    
562 root 1.119 This creates and returns a guard object. Nothing happens until the object
563 root 1.103 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 root 1.92 =item unblock_sub { ... }
595    
596     This utility function takes a BLOCK or code reference and "unblocks" it,
597 root 1.181 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 root 1.92
602 root 1.124 The reason this function exists is that many event libraries (such as the
603 root 1.92 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 root 1.181 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 root 1.92
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 root 1.181 disk, for example.
612 root 1.92
613     In short: simply use C<unblock_sub { ... }> instead of C<sub { ... }> when
614     creating event callbacks that want to block.
615    
616 root 1.181 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 root 1.183 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 root 1.92 =cut
627    
628     our @unblock_queue;
629    
630 root 1.105 # 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 root 1.132 our $unblock_scheduler = new Coro sub {
635 root 1.92 while () {
636     while (my $cb = pop @unblock_queue) {
637 root 1.105 # this is an inlined copy of async_pool
638 root 1.134 my $coro = (pop @async_pool) || new Coro \&pool_handler;
639 root 1.105
640     $coro->{_invoke} = $cb;
641     $coro->ready;
642     cede; # for short-lived callbacks, this reduces pressure on the coro pool
643 root 1.92 }
644 root 1.105 schedule; # sleep well
645 root 1.92 }
646     };
647 root 1.132 $unblock_scheduler->desc ("[unblock_sub scheduler]");
648 root 1.92
649     sub unblock_sub(&) {
650     my $cb = shift;
651    
652     sub {
653 root 1.105 unshift @unblock_queue, [$cb, @_];
654 root 1.92 $unblock_scheduler->ready;
655     }
656     }
657    
658     =back
659    
660 root 1.8 =cut
661 root 1.2
662 root 1.8 1;
663 root 1.14
664 root 1.17 =head1 BUGS/LIMITATIONS
665 root 1.14
666 root 1.181 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 root 1.9
672     =head1 SEE ALSO
673    
674 root 1.181 Event-Loop integration: L<Coro::AnyEvent>, L<Coro::EV>, L<Coro::Event>.
675 root 1.152
676     Debugging: L<Coro::Debug>.
677    
678     Support/Utility: L<Coro::Specific>, L<Coro::Util>.
679 root 1.67
680     Locking/IPC: L<Coro::Signal>, L<Coro::Channel>, L<Coro::Semaphore>, L<Coro::SemaphoreSet>, L<Coro::RWLock>.
681    
682 root 1.181 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 root 1.152
686 root 1.181 XS API: L<Coro::MakeMaker>.
687 root 1.67
688 root 1.181 Low level Configuration, Coroutine Environment: L<Coro::State>.
689 root 1.1
690     =head1 AUTHOR
691    
692 root 1.66 Marc Lehmann <schmorp@schmorp.de>
693 root 1.64 http://home.schmorp.de/
694 root 1.1
695     =cut
696