|Did you know ...||Search Documentation:|
|thread_pool.pl -- Resource bounded thread management|
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_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.
waitoption of thread_create_in_pool/4 and the
backlogoption 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
state of a thread. Threads can be created both
normal and must be joined using thread_join/2 if they are not
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, ).