… | |
… | |
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 |