It looks like a great way to use generic resource pools. Specifically, I’m thinking about how HTTP::Server reuses instances of HTTP::Server::Response or how Fiber stacks are reused by the Crystal runtime. You could probably also use it to maintain a Fiber pool for doing things concurrently without the risk of unbounded fiber proliferation (thinking along the lines of Sidekiq’s static thread pool).
For connection pooling specifically, DB::Pool from crystal-lang/crystal-db has been decoupled from DB-specific connections and can be used as a pool for any type of connection as of 0.10.0, and it’s really well optimized. For example, it allows concurrent connection creation to reduce the effect of latency (it unlocks the mutex while connecting) and shedding excess idle connections after a volume spike for elasticity. If you need a connection pool specifically, I’d stick with that.
Examples of DB::Pool used outside of DB:
-
My
awsshard (which I just realized needs an updatedREADME) uses it to maintain a pool ofHTTP::Clients -
My
redisshard uses it to maintain a pool ofRedis::Connections