… | |
… | |
67 | |
67 | |
68 | our $idle; # idle handler |
68 | our $idle; # idle handler |
69 | our $main; # main coroutine |
69 | our $main; # main coroutine |
70 | our $current; # current coroutine |
70 | our $current; # current coroutine |
71 | |
71 | |
72 | our $VERSION = 4.745; |
72 | our $VERSION = 4.803; |
73 | |
73 | |
74 | our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub); |
74 | our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub); |
75 | our %EXPORT_TAGS = ( |
75 | our %EXPORT_TAGS = ( |
76 | prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)], |
76 | prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)], |
77 | ); |
77 | ); |
… | |
… | |
221 | terminate or join on it (although you are allowed to), and you get a |
221 | 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 |
222 | coroutine that might have executed other code already (which can be good |
223 | or bad :). |
223 | or bad :). |
224 | |
224 | |
225 | On the plus side, this function is faster than creating (and destroying) |
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 |
226 | a completly new coroutine, so if you need a lot of generic coroutines in |
227 | quick successsion, use C<async_pool>, not C<async>. |
227 | quick successsion, use C<async_pool>, not C<async>. |
228 | |
228 | |
229 | The code block is executed in an C<eval> context and a warning will be |
229 | The code block is executed in an C<eval> context and a warning will be |
230 | issued in case of an exception instead of terminating the program, as |
230 | 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> |
231 | C<async> does. As the coroutine is being reused, stuff like C<on_destroy> |
… | |
… | |
235 | |
235 | |
236 | The priority will be reset to C<0> after each run, tracing will be |
236 | The priority will be reset to C<0> after each run, tracing will be |
237 | disabled, the description will be reset and the default output filehandle |
237 | disabled, the description will be reset and the default output filehandle |
238 | gets restored, so you can change all these. Otherwise the coroutine will |
238 | gets restored, so you can change all these. Otherwise the coroutine will |
239 | be re-used "as-is": most notably if you change other per-coroutine global |
239 | be re-used "as-is": most notably if you change other per-coroutine global |
240 | stuff such as C<$/> you I<must needs> to revert that change, which is most |
240 | stuff such as C<$/> you I<must needs> revert that change, which is most |
241 | simply done by using local as in: C< local $/ >. |
241 | simply done by using local as in: C<< local $/ >>. |
242 | |
242 | |
243 | The pool size is limited to C<8> idle coroutines (this can be adjusted by |
243 | The idle pool size is limited to C<8> idle coroutines (this can be |
244 | changing $Coro::POOL_SIZE), and there can be as many non-idle coros as |
244 | adjusted by changing $Coro::POOL_SIZE), but there can be as many non-idle |
245 | required. |
245 | coros as required. |
246 | |
246 | |
247 | If you are concerned about pooled coroutines growing a lot because a |
247 | If you are concerned about pooled coroutines growing a lot because a |
248 | single C<async_pool> used a lot of stackspace you can e.g. C<async_pool |
248 | 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 |
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 |
250 | addition to that, when the stacks used by a handler grows larger than 16kb |