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