[Haskell-cafe] Re: Joels Time Leak

Simon Marlow simonmar at microsoft.com
Wed Jan 4 05:49:53 EST 2006

On 03 January 2006 17:32, Chris Kuklewicz wrote:

> Thanks for the answer, but I should I written a longer comment. I have
> added such a longer comment below:
> Simon Marlow wrote:
>> Chris Kuklewicz wrote:
>>> Another comment: between 1000's of threads and writing a custom
>>> continuation based scheduler, what about using a thread pool?  Does
>>> anyone have a library with a "fork-IO-Pool" command?
>> You don't need a thread pool, because threads are so cheap.  Thread
>> pools are just a workaround for lack of lightweight concurrency.
>> Cheers,
>>     Simon
> Since the round-robin scheduler has (0.02 * N) seconds of delay for N
> therads, then one could trade off latency between time spent waiting
> for the thread pool to start a job and time spend running the job and
> getting interrupted.
> In the limit of 1 worker thread, all the latency is waiting to get
> run, and there are no interruptions, so the time taken *while
> running* is very short.  With 10 threads, there can be a delay to
> start, and each interruption adds 0.2 seconds to the job's run time
> once it has started. 
> For a server, the client requests queue up and wait for room in the
> thread pool, and the pool is kept small enough that the
> round-robin-schedular-delay keeps requests from timing out while being
> serviced.  Otherwise 1000 client requests would cause 20 seconds of
> reschedule penalty for all threads and they could all timeout.  With a
> thread pool, one can drop threads that have been waiting for too long
> instead of running them, so those threads will timeout. But the pool
> keeps servicing at least some of the client requests on time.
> All hypothetical to me, of course.

I see - you want to use a thread pool as a way of restricting
parallelism, so as to control latency.  Good idea, it would make a
useful library.


More information about the Haskell-Cafe mailing list