[Haskell-cafe] External system connections
Brandon Allbery
allbery.b at gmail.com
Mon Jul 11 01:38:29 CEST 2011
On Sun, Jul 10, 2011 at 19:16, Richard Wallace
<rwallace at thewallacepack.net> wrote:
> On Sun, Jul 10, 2011 at 2:54 PM, Brandon Allbery <allbery.b at gmail.com> wrote:
> One thing I'd have to be careful to handle is iIf multiple worker
> threads find that the token is now invalid. In that case they would
> all send the token renewal request to the dispatcher and they would
> each try and do the re-auth. To avoid that, part of the token renewal
One of the reasons to send the request back to the dispatcher instead
of doing it inline is so that the dispatcher can note that a renewal
request is already in flight (which it needs to know anyway, so it can
block other requests) and wake all threads waiting on it when it's
done, instead of having multiple renewals in flight.
> 1. Now that I rethink it, it seems like you are suggesting the
> resource is the worker threads. Is that right? When I read what you
> were talking about above with the dispatcher thread I had thought it
> would use forkIO to start the worker threads. The worker threads
> would read from a Chan that the dispatcher wrote to. In that way,
> the dispatcher doesn't have to worry about worker threads being
> available. Am I misunderstanding something?
The point of a pool is so (a) you can throttle it in special cases,
such as when you need to renew the token, and (b) so you don't find
yourself juggling a couple thousand threads if things get unexpectedly
busy (or buggy). You can limit the pool to something sensible
(probably something like 4 during development and debugging so things
can't get too out of hand) and increased later; plus, the pool manager
will provide the primitives to deal with managing shared resources
(such as your token) within the pool.
--
brandon s allbery allbery.b at gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
More information about the Haskell-Cafe
mailing list