The module library(thread_pool) manages threads in pools. A pool defines properties of its member threads and the maximum number of threads that can coexist in the pool. The call thread_create_in_pool/4 allocates a thread in the pool, just like thread_create/3. If the pool is fully allocated it can be asked to wait or raise an error.
The library has been designed to deal with server applications that receive a variety of requests, such as HTTP servers. Simply starting a thread for each request is a bit too simple minded for such servers:
Using this library, one can define a pool for each set of tasks with comparable characteristics and create threads in this pool. Unlike the worker-pool model, threads are not started immediately. Depending on the design, both approaches can be attractive.
The library is implemented by means of a manager thread with the fixed
thread id __thread_pool_manager
. All state is maintained in this
manager thread, which receives and processes requests to create and
destroy pools, create threads in a pool and handle messages from
terminated threads. Thread pools are not saved in a saved state and
must therefore be recreated using the initialization/1 directive or
otherwise during startup of the application.
wait
option of
thread_create_in_pool/4 and the backlog
option described
below. Options are passed to thread_create/3, except for
infinite
. Otherwise it must be a non-negative integer.
Using backlog(0)
will never delay thread creation for this
pool.
The pooling mechanism does not interact with the detached
state of a thread. Threads can be created both detached
and
normal and must be joined using thread_join/2 if they are not
detached.
true
(default) and the pool is full, wait until a
member of the pool completes. If false
, throw a
resource_error.media
, which holds a
maximum of 20 threads.
:- multifile thread_pool:create_pool/1. thread_pool:create_pool(media) :- thread_pool_create(media, 20, []).