[Haskell-cafe] Re: Joels Time Leak

[Simon Marlow]

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.

Cheers,
	Simon