resource-pool- A high-performance striped resource pooling implementation

MaintainerBryan O'Sullivan <>



A high-performance striped pooling abstraction for managing flexibly-sized collections of resources such as database connections.

"Striped" means that a single Pool consists of several sub-pools, each managed independently. A stripe size of 1 is fine for many applications, and probably what you should choose by default. Larger stripe sizes will lead to reduced contention in high-performance multicore applications, at a trade-off of causing the maximum number of simultaneous resources in use to grow.



data Pool a Source


Show (Pool a) 



:: IO a

Action that creates a new resource.

-> (a -> IO ())

Action that destroys an existing resource.

-> Int

Stripe count. The number of distinct sub-pools to maintain. The smallest acceptable value is 1.

-> NominalDiffTime

Amount of time for which an unused resource is kept open. The smallest acceptable value is 0.5 seconds.

The elapsed time before destroying a resource may be a little longer than requested, as the reaper thread wakes at 1-second intervals.

-> Int

Maximum number of resources to keep open per stripe. The smallest acceptable value is 1.

Requests for resources will block if this limit is reached on a single stripe, even if other stripes have idle resources available.

-> IO (Pool a) 

withResource :: MonadControlIO m => Pool a -> (a -> m b) -> m bSource

Temporarily take a resource from a Pool, perform an action with it, and return it to the pool afterwards.

  • If the pool has an idle resource available, it is used immediately.
  • Otherwise, if the maximum number of resources has not yet been reached, a new resource is created and used.
  • If the maximum number of resources has been reached, this function blocks until a resource becomes available.

If the action throws an exception of any type, the resource is destroyed, and not returned to the pool.

It probably goes without saying that you should never manually destroy a pooled resource, as doing so will almost certainly cause a subsequent user (who expects the resource to be valid) to throw an exception.