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, []).