| … | |
… | |
| 212 | Similar to C<async>, but uses a coroutine pool, so you should not call |
212 | Similar to C<async>, but uses a coroutine pool, so you should not call |
| 213 | terminate or join on it (although you are allowed to), and you get a |
213 | terminate or join on it (although you are allowed to), and you get a |
| 214 | coroutine that might have executed other code already (which can be good |
214 | coroutine that might have executed other code already (which can be good |
| 215 | or bad :). |
215 | or bad :). |
| 216 | |
216 | |
| 217 | On the plus side, this function is faster than creating (and destroying) |
217 | On the plus side, this function is about twice as fast as creating (and |
| 218 | a completly new coroutine, so if you need a lot of generic coroutines in |
218 | destroying) a completely new coroutine, so if you need a lot of generic |
| 219 | quick successsion, use C<async_pool>, not C<async>. |
219 | coroutines in quick successsion, use C<async_pool>, not C<async>. |
| 220 | |
220 | |
| 221 | The code block is executed in an C<eval> context and a warning will be |
221 | The code block is executed in an C<eval> context and a warning will be |
| 222 | issued in case of an exception instead of terminating the program, as |
222 | issued in case of an exception instead of terminating the program, as |
| 223 | C<async> does. As the coroutine is being reused, stuff like C<on_destroy> |
223 | C<async> does. As the coroutine is being reused, stuff like C<on_destroy> |
| 224 | will not work in the expected way, unless you call terminate or cancel, |
224 | will not work in the expected way, unless you call terminate or cancel, |
| … | |
… | |
| 390 | } else { |
390 | } else { |
| 391 | $self->{_status} = [@_]; |
391 | $self->{_status} = [@_]; |
| 392 | $self->_cancel; |
392 | $self->_cancel; |
| 393 | } |
393 | } |
| 394 | } |
394 | } |
|
|
395 | |
|
|
396 | =item $coroutine->schedule_to |
|
|
397 | |
|
|
398 | Puts the current coroutine to sleep (like C<Coro::schedule>), but instead |
|
|
399 | of continuing with the next coro from the ready queue, always switch to |
|
|
400 | the given coroutine object (regardless of priority etc.). The readyness |
|
|
401 | state of that coroutine isn't changed. |
|
|
402 | |
|
|
403 | This is an advanced method for special cases - I'd love to hear about any |
|
|
404 | uses for this one. |
|
|
405 | |
|
|
406 | =item $coroutine->cede_to |
|
|
407 | |
|
|
408 | Like C<schedule_to>, but puts the current coroutine into the ready |
|
|
409 | queue. This has the effect of temporarily switching to the given |
|
|
410 | coroutine, and continuing some time later. |
|
|
411 | |
|
|
412 | This is an advanced method for special cases - I'd love to hear about any |
|
|
413 | uses for this one. |
| 395 | |
414 | |
| 396 | =item $coroutine->throw ([$scalar]) |
415 | =item $coroutine->throw ([$scalar]) |
| 397 | |
416 | |
| 398 | If C<$throw> is specified and defined, it will be thrown as an exception |
417 | If C<$throw> is specified and defined, it will be thrown as an exception |
| 399 | inside the coroutine at the next convenient point in time. Otherwise |
418 | inside the coroutine at the next convenient point in time. Otherwise |
