On Sun, Jun 12, 2011 at 10:47 AM, Ertugrul Soeylemez
Hello Michael, hello fellow haskellers,
there is something, which has bothered me for quite a while, but now it has become a serious problem for me, because I see it as a bug, and there is no elegant way to work around it.
I wonder if it's the right semantics for Data.Pool to simply fail with an exception, if the pool is exhausted. It would be much more appropriate, if it would just block, until a resource becomes available. Otherwise it's just /safe/ for multi-threading, but not really /useful/ for it.
I noticed this when I launched 512 worker threads, but my pool had only 16 database connections. I need the pool to block, until a resource is available.
It's also common that my Yesod site just returns an internal server error, when the pool is exhausted, so you can only handle as many connections successfully as there are database connections. I would expect Yesod to wait for a connection to become available instead of simply blowing the request.
Blocking should at least be an option and be somehow reachable from Yesod/persistent.
Greets, Ertugrul
-- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Well, there's withPoolAllocate, which will allocate a new resource if the pool is empty. I don't see a problem adding withPoolBlock as well. Using threadDelay, this is possible already: withPoolBlock pool f = do x <- withPool f maybe (liftIO (threadDelay timeout) >> withPoolBlock pool f) return x Though I'm sure we could do better than that. Michael