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