ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/Coro/Coro.pm
Revision: 1.185
Committed: Tue May 20 15:07:03 2008 UTC (16 years ago) by root
Branch: MAIN
CVS Tags: rel-4_71
Changes since 1.184: +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     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.185 our $VERSION = '4.71';
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.151 last if $@ eq "\3async_pool terminate\2\n";
272 root 1.105 warn $@ if $@;
273 root 1.106 }
274     }
275 root 1.105
276     sub async_pool(&@) {
277     # this is also inlined into the unlock_scheduler
278 root 1.135 my $coro = (pop @async_pool) || new Coro \&pool_handler;
279 root 1.105
280     $coro->{_invoke} = [@_];
281     $coro->ready;
282    
283     $coro
284     }
285    
286 root 1.181 =back
287    
288     =head2 STATIC METHODS
289    
290     Static methods are actually functions that operate on the current coroutine.
291    
292     =over 4
293    
294 root 1.8 =item schedule
295 root 1.6
296 root 1.181 Calls the scheduler. The scheduler will find the next coroutine that is
297     to be run from the ready queue and switches to it. The next coroutine
298     to be run is simply the one with the highest priority that is longest
299     in its ready queue. If there is no coroutine ready, it will clal the
300     C<$Coro::idle> hook.
301    
302     Please note that the current coroutine will I<not> be put into the ready
303     queue, so calling this function usually means you will never be called
304     again unless something else (e.g. an event handler) calls C<< ->ready >>,
305     thus waking you up.
306    
307     This makes C<schedule> I<the> generic method to use to block the current
308     coroutine and wait for events: first you remember the current coroutine in
309     a variable, then arrange for some callback of yours to call C<< ->ready
310     >> on that once some event happens, and last you call C<schedule> to put
311     yourself to sleep. Note that a lot of things can wake your coroutine up,
312     so you need to check wether the event indeed happened, e.g. by storing the
313     status in a variable.
314 root 1.91
315     The canonical way to wait on external events is this:
316    
317     {
318 root 1.92 # remember current coroutine
319 root 1.91 my $current = $Coro::current;
320    
321     # register a hypothetical event handler
322     on_event_invoke sub {
323     # wake up sleeping coroutine
324     $current->ready;
325     undef $current;
326     };
327    
328 root 1.124 # call schedule until event occurred.
329 root 1.91 # in case we are woken up for other reasons
330     # (current still defined), loop.
331     Coro::schedule while $current;
332     }
333 root 1.1
334 root 1.22 =item cede
335 root 1.1
336 root 1.181 "Cede" to other coroutines. This function puts the current coroutine into
337     the ready queue and calls C<schedule>, which has the effect of giving
338     up the current "timeslice" to other coroutines of the same or higher
339     priority. Once your coroutine gets its turn again it will automatically be
340     resumed.
341    
342     This function is often called C<yield> in other languages.
343 root 1.7
344 root 1.102 =item Coro::cede_notself
345    
346 root 1.181 Works like cede, but is not exported by default and will cede to I<any>
347     coroutine, regardless of priority. This is useful sometimes to ensure
348     progress is made.
349 root 1.102
350 root 1.40 =item terminate [arg...]
351 root 1.7
352 root 1.92 Terminates the current coroutine with the given status values (see L<cancel>).
353 root 1.13
354 root 1.141 =item killall
355    
356     Kills/terminates/cancels all coroutines except the currently running
357     one. This is useful after a fork, either in the child or the parent, as
358     usually only one of them should inherit the running coroutines.
359    
360 root 1.181 Note that while this will try to free some of the main programs resources,
361     you cnanot free all of them, so if a coroutine that is not the main
362     program calls this function, there will be some one-time resource leak.
363    
364 root 1.1 =cut
365    
366 root 1.8 sub terminate {
367 pcg 1.59 $current->cancel (@_);
368 root 1.1 }
369 root 1.6
370 root 1.141 sub killall {
371     for (Coro::State::list) {
372     $_->cancel
373     if $_ != $current && UNIVERSAL::isa $_, "Coro";
374     }
375     }
376    
377 root 1.8 =back
378    
379 root 1.92 =head2 COROUTINE METHODS
380 root 1.8
381 root 1.181 These are the methods you can call on coroutine objects (or to create
382     them).
383 root 1.6
384 root 1.8 =over 4
385    
386 root 1.13 =item new Coro \&sub [, @args...]
387 root 1.8
388 root 1.181 Create a new coroutine and return it. When the sub returns, the coroutine
389 root 1.40 automatically terminates as if C<terminate> with the returned values were
390 root 1.181 called. To make the coroutine run you must first put it into the ready
391     queue by calling the ready method.
392 root 1.13
393 root 1.145 See C<async> and C<Coro::State::new> for additional info about the
394     coroutine environment.
395 root 1.89
396 root 1.6 =cut
397    
398 root 1.94 sub _run_coro {
399 root 1.13 terminate &{+shift};
400     }
401    
402 root 1.8 sub new {
403     my $class = shift;
404 root 1.83
405 root 1.94 $class->SUPER::new (\&_run_coro, @_)
406 root 1.8 }
407 root 1.6
408 root 1.92 =item $success = $coroutine->ready
409 root 1.1
410 root 1.181 Put the given coroutine into the end of its ready queue (there is one
411     queue for each priority) and return true. If the coroutine is already in
412     the ready queue, do nothing and return false.
413    
414     This ensures that the scheduler will resume this coroutine automatically
415     once all the coroutines of higher priority and all coroutines of the same
416     priority that were put into the ready queue earlier have been resumed.
417 root 1.1
418 root 1.92 =item $is_ready = $coroutine->is_ready
419 root 1.90
420 root 1.92 Return wether the coroutine is currently the ready queue or not,
421 root 1.28
422 root 1.92 =item $coroutine->cancel (arg...)
423 root 1.28
424 root 1.92 Terminates the given coroutine and makes it return the given arguments as
425 root 1.103 status (default: the empty list). Never returns if the coroutine is the
426     current coroutine.
427 root 1.28
428     =cut
429    
430     sub cancel {
431 pcg 1.59 my $self = shift;
432 root 1.142 $self->{_status} = [@_];
433 root 1.103
434     if ($current == $self) {
435     push @destroy, $self;
436     $manager->ready;
437     &schedule while 1;
438     } else {
439     $self->_cancel;
440     }
441 root 1.40 }
442    
443 root 1.92 =item $coroutine->join
444 root 1.40
445     Wait until the coroutine terminates and return any values given to the
446 root 1.143 C<terminate> or C<cancel> functions. C<join> can be called concurrently
447 root 1.181 from multiple coroutines, and all will be resumed and given the status
448     return once the C<$coroutine> terminates.
449 root 1.40
450     =cut
451    
452     sub join {
453     my $self = shift;
454 root 1.103
455 root 1.142 unless ($self->{_status}) {
456 root 1.103 my $current = $current;
457    
458 root 1.142 push @{$self->{_on_destroy}}, sub {
459 root 1.103 $current->ready;
460     undef $current;
461     };
462    
463     &schedule while $current;
464 root 1.40 }
465 root 1.103
466 root 1.142 wantarray ? @{$self->{_status}} : $self->{_status}[0];
467 root 1.31 }
468    
469 root 1.101 =item $coroutine->on_destroy (\&cb)
470    
471     Registers a callback that is called when this coroutine gets destroyed,
472     but before it is joined. The callback gets passed the terminate arguments,
473 root 1.181 if any, and I<must not> die, under any circumstances.
474 root 1.101
475     =cut
476    
477     sub on_destroy {
478     my ($self, $cb) = @_;
479    
480 root 1.142 push @{ $self->{_on_destroy} }, $cb;
481 root 1.101 }
482    
483 root 1.92 =item $oldprio = $coroutine->prio ($newprio)
484 root 1.31
485 root 1.41 Sets (or gets, if the argument is missing) the priority of the
486 root 1.92 coroutine. Higher priority coroutines get run before lower priority
487     coroutines. Priorities are small signed integers (currently -4 .. +3),
488 root 1.41 that you can refer to using PRIO_xxx constants (use the import tag :prio
489     to get then):
490 root 1.31
491     PRIO_MAX > PRIO_HIGH > PRIO_NORMAL > PRIO_LOW > PRIO_IDLE > PRIO_MIN
492     3 > 1 > 0 > -1 > -3 > -4
493    
494     # set priority to HIGH
495     current->prio(PRIO_HIGH);
496    
497     The idle coroutine ($Coro::idle) always has a lower priority than any
498     existing coroutine.
499    
500 root 1.92 Changing the priority of the current coroutine will take effect immediately,
501     but changing the priority of coroutines in the ready queue (but not
502 root 1.31 running) will only take effect after the next schedule (of that
503 root 1.92 coroutine). This is a bug that will be fixed in some future version.
504 root 1.31
505 root 1.92 =item $newprio = $coroutine->nice ($change)
506 root 1.31
507     Similar to C<prio>, but subtract the given value from the priority (i.e.
508     higher values mean lower priority, just as in unix).
509    
510 root 1.92 =item $olddesc = $coroutine->desc ($newdesc)
511 root 1.41
512     Sets (or gets in case the argument is missing) the description for this
513 root 1.92 coroutine. This is just a free-form string you can associate with a coroutine.
514 root 1.41
515 root 1.142 This method simply sets the C<< $coroutine->{desc} >> member to the given string. You
516     can modify this member directly if you wish.
517    
518 root 1.150 =item $coroutine->throw ([$scalar])
519    
520     If C<$throw> is specified and defined, it will be thrown as an exception
521     inside the coroutine at the next convinient point in time (usually after
522     it gains control at the next schedule/transfer/cede). Otherwise clears the
523     exception object.
524    
525     The exception object will be thrown "as is" with the specified scalar in
526     C<$@>, i.e. if it is a string, no line number or newline will be appended
527     (unlike with C<die>).
528    
529     This can be used as a softer means than C<cancel> to ask a coroutine to
530     end itself, although there is no guarentee that the exception will lead to
531     termination, and if the exception isn't caught it might well end the whole
532     program.
533    
534 root 1.41 =cut
535    
536     sub desc {
537     my $old = $_[0]{desc};
538     $_[0]{desc} = $_[1] if @_ > 1;
539     $old;
540 root 1.8 }
541 root 1.1
542 root 1.8 =back
543 root 1.2
544 root 1.97 =head2 GLOBAL FUNCTIONS
545 root 1.92
546     =over 4
547    
548 root 1.97 =item Coro::nready
549    
550     Returns the number of coroutines that are currently in the ready state,
551 root 1.181 i.e. that can be switched to by calling C<schedule> directory or
552     indirectly. The value C<0> means that the only runnable coroutine is the
553     currently running one, so C<cede> would have no effect, and C<schedule>
554     would cause a deadlock unless there is an idle handler that wakes up some
555     coroutines.
556 root 1.97
557 root 1.103 =item my $guard = Coro::guard { ... }
558    
559 root 1.119 This creates and returns a guard object. Nothing happens until the object
560 root 1.103 gets destroyed, in which case the codeblock given as argument will be
561     executed. This is useful to free locks or other resources in case of a
562     runtime error or when the coroutine gets canceled, as in both cases the
563     guard block will be executed. The guard object supports only one method,
564     C<< ->cancel >>, which will keep the codeblock from being executed.
565    
566     Example: set some flag and clear it again when the coroutine gets canceled
567     or the function returns:
568    
569     sub do_something {
570     my $guard = Coro::guard { $busy = 0 };
571     $busy = 1;
572    
573     # do something that requires $busy to be true
574     }
575    
576     =cut
577    
578     sub guard(&) {
579     bless \(my $cb = $_[0]), "Coro::guard"
580     }
581    
582     sub Coro::guard::cancel {
583     ${$_[0]} = sub { };
584     }
585    
586     sub Coro::guard::DESTROY {
587     ${$_[0]}->();
588     }
589    
590    
591 root 1.92 =item unblock_sub { ... }
592    
593     This utility function takes a BLOCK or code reference and "unblocks" it,
594 root 1.181 returning a new coderef. Unblocking means that calling the new coderef
595     will return immediately without blocking, returning nothing, while the
596     original code ref will be called (with parameters) from within another
597     coroutine.
598 root 1.92
599 root 1.124 The reason this function exists is that many event libraries (such as the
600 root 1.92 venerable L<Event|Event> module) are not coroutine-safe (a weaker form
601     of thread-safety). This means you must not block within event callbacks,
602 root 1.181 otherwise you might suffer from crashes or worse. The only event library
603     currently known that is safe to use without C<unblock_sub> is L<EV>.
604 root 1.92
605     This function allows your callbacks to block by executing them in another
606     coroutine where it is safe to block. One example where blocking is handy
607     is when you use the L<Coro::AIO|Coro::AIO> functions to save results to
608 root 1.181 disk, for example.
609 root 1.92
610     In short: simply use C<unblock_sub { ... }> instead of C<sub { ... }> when
611     creating event callbacks that want to block.
612    
613 root 1.181 If your handler does not plan to block (e.g. simply sends a message to
614     another coroutine, or puts some other coroutine into the ready queue),
615     there is no reason to use C<unblock_sub>.
616    
617 root 1.183 Note that you also need to use C<unblock_sub> for any other callbacks that
618     are indirectly executed by any C-based event loop. For example, when you
619     use a module that uses L<AnyEvent> (and you use L<Coro::AnyEvent>) and it
620     provides callbacks that are the result of some event callback, then you
621     must not block either, or use C<unblock_sub>.
622    
623 root 1.92 =cut
624    
625     our @unblock_queue;
626    
627 root 1.105 # we create a special coro because we want to cede,
628     # to reduce pressure on the coro pool (because most callbacks
629     # return immediately and can be reused) and because we cannot cede
630     # inside an event callback.
631 root 1.132 our $unblock_scheduler = new Coro sub {
632 root 1.92 while () {
633     while (my $cb = pop @unblock_queue) {
634 root 1.105 # this is an inlined copy of async_pool
635 root 1.134 my $coro = (pop @async_pool) || new Coro \&pool_handler;
636 root 1.105
637     $coro->{_invoke} = $cb;
638     $coro->ready;
639     cede; # for short-lived callbacks, this reduces pressure on the coro pool
640 root 1.92 }
641 root 1.105 schedule; # sleep well
642 root 1.92 }
643     };
644 root 1.132 $unblock_scheduler->desc ("[unblock_sub scheduler]");
645 root 1.92
646     sub unblock_sub(&) {
647     my $cb = shift;
648    
649     sub {
650 root 1.105 unshift @unblock_queue, [$cb, @_];
651 root 1.92 $unblock_scheduler->ready;
652     }
653     }
654    
655     =back
656    
657 root 1.8 =cut
658 root 1.2
659 root 1.8 1;
660 root 1.14
661 root 1.17 =head1 BUGS/LIMITATIONS
662 root 1.14
663 root 1.181 This module is not perl-pseudo-thread-safe. You should only ever use this
664     module from the same thread (this requirement might be removed in the
665     future to allow per-thread schedulers, but Coro::State does not yet allow
666     this). I recommend disabling thread support and using processes, as this
667     is much faster and uses less memory.
668 root 1.9
669     =head1 SEE ALSO
670    
671 root 1.181 Event-Loop integration: L<Coro::AnyEvent>, L<Coro::EV>, L<Coro::Event>.
672 root 1.152
673     Debugging: L<Coro::Debug>.
674    
675     Support/Utility: L<Coro::Specific>, L<Coro::Util>.
676 root 1.67
677     Locking/IPC: L<Coro::Signal>, L<Coro::Channel>, L<Coro::Semaphore>, L<Coro::SemaphoreSet>, L<Coro::RWLock>.
678    
679 root 1.181 IO/Timers: L<Coro::Timer>, L<Coro::Handle>, L<Coro::Socket>, L<Coro::AIO>.
680    
681     Compatibility: L<Coro::LWP>, L<Coro::BDB>, L<Coro::Storable>, L<Coro::Select>.
682 root 1.152
683 root 1.181 XS API: L<Coro::MakeMaker>.
684 root 1.67
685 root 1.181 Low level Configuration, Coroutine Environment: L<Coro::State>.
686 root 1.1
687     =head1 AUTHOR
688    
689 root 1.66 Marc Lehmann <schmorp@schmorp.de>
690 root 1.64 http://home.schmorp.de/
691 root 1.1
692     =cut
693