[Haskell-cafe] pool: Why doesn't it block?
Michael Snoyman
michael at snoyman.com
Sun Jun 12 11:11:36 CEST 2011
On Sun, Jun 12, 2011 at 10:47 AM, Ertugrul Soeylemez <es at ertes.de> wrote:
> 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 at 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
More information about the Haskell-Cafe
mailing list