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 application that recieve 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.
at_exit is 
reserved for internal use by this library.
true (default) and the pool is full, wait until a member 
of the pool completes. If false, throw a resource_error.
false or the backlog limit has been 
reached.