The thread-pool-init function creates a new pool of user threads. A pool must be declared before it is used. For a plug-in to use the new pool, specify the pool parameter when loading the plug-in with the Init-class function load-modules. For more information, see load-modules.
This function is applicable in Init-class directives.
One reason to create a custom thread pool would be if a plug-in is not thread-aware, in which case you can set the maximum number of threads in the pool to 1. The older parameter NativeThread=yes always engages one default native pool, called NativePool.
The native pool on UNIX is normally not engaged, as all threads are kernel-level threads. In addition, native thread pool parameters can be added to the magnus.conf file for convenience. For more information, see Chapter 4, Syntax and Use of magnus.conf.
The following table describes the thread-pool-init parameters.
Table 5–9 thread-pool-init Parameters
Parameter |
Description |
---|---|
The name of the thread pool. |
|
The maximum number of threads in the pool. |
|
The minimum number of threads in the pool. |
|
The size of the pool queue. If all threads in the pool are busy, further request-handling threads that need to get a thread from the pool wait in the pool queue. The number of request-handling threads that can wait in the queue is limited by the queue size. If the queue is full, the next request-handling thread that comes to the queue is turned away, with the result that the request is turned down. But the request-handling thread remains free to handle another request instead of becoming locked up in the queue. |
|
Stack size of each thread in the native (kernel) thread pool. |
Init fn="thread-pool-init" name="my-custom-pool" minthreads="1" maxthreads="5" queuesize="200" Init fn="load-modules" shlib="myplugin.dll" funcs="tracker" pool="my-custom-pool"