| … | |
… | |
| 235 | and the call actually being executed. During this time, the |
235 | and the call actually being executed. During this time, the |
| 236 | parameters passed to this function are effectively read-only - |
236 | parameters passed to this function are effectively read-only - |
| 237 | modifying them after the call and before the callback is invoked |
237 | modifying them after the call and before the callback is invoked |
| 238 | causes undefined behaviour. |
238 | causes undefined behaviour. |
| 239 | |
239 | |
|
|
240 | $cpus = AnyEvent::Fork::Pool::ncpu [$default_cpus] |
|
|
241 | ($cpus, $eus) = AnyEvent::Fork::Pool::ncpu [$default_cpus] |
|
|
242 | Tries to detect the number of CPUs ($cpus often called cpu cores |
|
|
243 | nowadays) and execution units ($eus) which include e.g. extra |
|
|
244 | hyperthreaded units). When $cpus cannot be determined reliably, |
|
|
245 | $default_cpus is returned for both values, or 1 if it is missing. |
|
|
246 | |
|
|
247 | For normal CPU bound uses, it is wise to have as many worker |
|
|
248 | processes as CPUs in the system ($cpus), if nothing else uses the |
|
|
249 | CPU. Using hyperthreading is usually detrimental to performance, but |
|
|
250 | in those rare cases where that really helps it might be beneficial |
|
|
251 | to use more workers ($eus). |
|
|
252 | |
|
|
253 | Currently, /proc/cpuinfo is parsed on GNU/Linux systems for both |
|
|
254 | $cpus and $eu, and on {Free,Net,Open}BSD, sysctl -n hw.ncpu is used |
|
|
255 | for $cpus. |
|
|
256 | |
|
|
257 | Example: create a worker pool with as many workers as cpu cores, or |
|
|
258 | 2, if the actual number could not be determined. |
|
|
259 | |
|
|
260 | $fork->AnyEvent::Fork::Pool::run ("myworker::function", |
|
|
261 | max => (scalar AnyEvent::Fork::Pool::ncpu 2), |
|
|
262 | ); |
|
|
263 | |
| 240 | CHILD USAGE |
264 | CHILD USAGE |
| 241 | In addition to the AnyEvent::Fork::RPC API, this module implements one |
265 | In addition to the AnyEvent::Fork::RPC API, this module implements one |
| 242 | more child-side function: |
266 | more child-side function: |
| 243 | |
267 | |
| 244 | AnyEvent::Fork::Pool::retire () |
268 | AnyEvent::Fork::Pool::retire () |
| … | |
… | |
| 256 | Retiring a worker can be useful to gracefully shut it down when the |
280 | Retiring a worker can be useful to gracefully shut it down when the |
| 257 | worker deems this useful. For example, after executing a job, one |
281 | worker deems this useful. For example, after executing a job, one |
| 258 | could check the process size or the number of jobs handled so far, |
282 | could check the process size or the number of jobs handled so far, |
| 259 | and if either is too high, the worker could ask to get retired, to |
283 | and if either is too high, the worker could ask to get retired, to |
| 260 | avoid memory leaks to accumulate. |
284 | avoid memory leaks to accumulate. |
|
|
285 | |
|
|
286 | Example: retire a worker after it has handled roughly 100 requests. |
|
|
287 | |
|
|
288 | my $count = 0; |
|
|
289 | |
|
|
290 | sub my::worker { |
|
|
291 | |
|
|
292 | ++$count == 100 |
|
|
293 | and AnyEvent::Fork::Pool::retire (); |
|
|
294 | |
|
|
295 | ... normal code goes here |
|
|
296 | } |
| 261 | |
297 | |
| 262 | POOL PARAMETERS RECIPES |
298 | POOL PARAMETERS RECIPES |
| 263 | This section describes some recipes for pool paramaters. These are |
299 | This section describes some recipes for pool paramaters. These are |
| 264 | mostly meant for the synchronous RPC backend, as the asynchronous RPC |
300 | mostly meant for the synchronous RPC backend, as the asynchronous RPC |
| 265 | backend changes the rules considerably, making workers themselves |
301 | backend changes the rules considerably, making workers themselves |
