From wws at clozure.com  Tue Feb  9 14:39:25 2010
From: wws at clozure.com (Bill St. Clair)
Date: Tue, 09 Feb 2010 09:39:25 -0500
Subject: [Eager-future-devel] Hard-limit added to thread pool
Message-ID: <4B71739D.5080408@clozure.com>

I decided I wanted a way to put an upper-limit on the number of threads
created by the eager-future thread pool. Very simple change. Please
integrate it.

-Bill St. Clair
wws at clozure.com

$ darcs diff
diff -rN old-eager-future/package.lisp new-eager-future/package.lisp
5c5,6
<            #:%thread-pool-soft-limit)
---
>            #:%thread-pool-soft-limit
>            #:%thread-pool-hard-limit)
diff -rN old-eager-future/threads.lisp new-eager-future/threads.lisp
6a7
>    (hard-limit :accessor hard-limit :initform nil)
13a15
> (define-symbol-macro %thread-pool-hard-limit (hard-limit *thread-pool*))
42c44,46
<     (if (= (free-thread-counter thread-pool) (length (tasks thread-pool)))
---
>     (if (and (= (free-thread-counter thread-pool) (length (tasks
thread-pool)))
>              (or (null (hard-limit thread-pool))
>                  (< (length (threads thread-pool)) (hard-limit
thread-pool))))




From vsedach at gmail.com  Thu Feb 11 10:22:39 2010
From: vsedach at gmail.com (Vladimir Sedach)
Date: Thu, 11 Feb 2010 05:22:39 -0500
Subject: [Eager-future-devel] Hard-limit added to thread pool
In-Reply-To: <4B71739D.5080408@clozure.com>
References: <4B71739D.5080408@clozure.com>
Message-ID: <c07e645b1002110222t2374b637rab6730542793a121@mail.gmail.com>

Hi Bill,

The main reason I forked Eager Future from PCall is this behavior -
the semantics of having SELECT multiplex on futures that are waiting
on external events is very different when you can always guarantee
that that future will get assigned to a thread vs. when you let it lie
around in a queue. There's really no (easy/sane) way to guarantee any
kind of fairness in the latter scenario. Note that your patch wouldn't
even provide FIFO ordering for waiting tasks - the task list is a
stack. The former approach assumes that the underlying thread
implementation will be "reasonably fair" and everything will be
alright.

Of course this leaves the burden of resource management to the
application. The idea is that the application code can include a
better approach to scheduling tasks than a PCall-style FIFO queue
would provide.

Vladimir

2010/2/9 Bill St. Clair <wws at clozure.com>:
> I decided I wanted a way to put an upper-limit on the number of threads
> created by the eager-future thread pool. Very simple change. Please
> integrate it.
>
> -Bill St. Clair
> wws at clozure.com
>
> $ darcs diff
> diff -rN old-eager-future/package.lisp new-eager-future/package.lisp
> 5c5,6
> < ? ? ? ? ? ?#:%thread-pool-soft-limit)
> ---
>> ? ? ? ? ? ?#:%thread-pool-soft-limit
>> ? ? ? ? ? ?#:%thread-pool-hard-limit)
> diff -rN old-eager-future/threads.lisp new-eager-future/threads.lisp
> 6a7
>> ? ?(hard-limit :accessor hard-limit :initform nil)
> 13a15
>> (define-symbol-macro %thread-pool-hard-limit (hard-limit *thread-pool*))
> 42c44,46
> < ? ? (if (= (free-thread-counter thread-pool) (length (tasks thread-pool)))
> ---
>> ? ? (if (and (= (free-thread-counter thread-pool) (length (tasks
> thread-pool)))
>> ? ? ? ? ? ? ?(or (null (hard-limit thread-pool))
>> ? ? ? ? ? ? ? ? ?(< (length (threads thread-pool)) (hard-limit
> thread-pool))))
>
>
> _______________________________________________
> Eager-future-devel mailing list
> Eager-future-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/eager-future-devel
>



From vsedach at gmail.com  Sun Feb 21 07:14:16 2010
From: vsedach at gmail.com (Vladimir Sedach)
Date: Sun, 21 Feb 2010 02:14:16 -0500
Subject: [Eager-future-devel] Hard-limit added to thread pool
In-Reply-To: <4B73F516.9020706@clozure.com>
References: <4B71739D.5080408@clozure.com>
	<c07e645b1002110222t2374b637rab6730542793a121@mail.gmail.com>
	<4B73F516.9020706@clozure.com>
Message-ID: <c07e645b1002202314r781e1e27q3398c68a3b3f3d7d@mail.gmail.com>

You're right, it does make more sense to put in some kind of thread
pool open implementation mechanism than to try to build something on
top of the one thread pool that eager future provides. I've pushed
such a patch to the darcs repository; try it out.

Vladimir

2010/2/11 Bill St. Clair <wws at clozure.com>:
> On 2/11/10 5:22AM, Vladimir Sedach wrote:
>> Hi Bill,
>>
>> The main reason I forked Eager Future from PCall is this behavior -
>> the semantics of having SELECT multiplex on futures that are waiting
>> on external events is very different when you can always guarantee
>> that that future will get assigned to a thread vs. when you let it lie
>> around in a queue. There's really no (easy/sane) way to guarantee any
>> kind of fairness in the latter scenario. Note that your patch wouldn't
>> even provide FIFO ordering for waiting tasks - the task list is a
>> stack. The former approach assumes that the underlying thread
>> implementation will be "reasonably fair" and everything will be
>> alright.
>
> Understood.
>
>> Of course this leaves the burden of resource management to the
>> application. The idea is that the application code can include a
>> better approach to scheduling tasks than a PCall-style FIFO queue
>> would provide.
>
> And one of those ways, which happens to work for my application, is to
> use a PCall-style FIFO queue, which a few lines of code makes easy to
> add to Eager-future. Note that it's not the default. Documentation could
> warn of the potential problems with using it.
>
> Another possibility would be multiple thread pools with different
> properties, the one like the presently implemented one being the
> default, and optional parameters to pcall and friends to choose the pool
> to use. Yes, that hairs up Eager-Future, which is now gloriously simple,
> but that's the nature of the problem.
>
> -Bill
>
>> Vladimir
>>
>> 2010/2/9 Bill St. Clair <wws at clozure.com>:
>>> I decided I wanted a way to put an upper-limit on the number of threads
>>> created by the eager-future thread pool. Very simple change. Please
>>> integrate it.
>>>
>>> -Bill St. Clair
>>> wws at clozure.com
>>>
>>> $ darcs diff
>>> diff -rN old-eager-future/package.lisp new-eager-future/package.lisp
>>> 5c5,6
>>> < ? ? ? ? ? ?#:%thread-pool-soft-limit)
>>> ---
>>>> ? ? ? ? ? ?#:%thread-pool-soft-limit
>>>> ? ? ? ? ? ?#:%thread-pool-hard-limit)
>>> diff -rN old-eager-future/threads.lisp new-eager-future/threads.lisp
>>> 6a7
>>>> ? ?(hard-limit :accessor hard-limit :initform nil)
>>> 13a15
>>>> (define-symbol-macro %thread-pool-hard-limit (hard-limit *thread-pool*))
>>> 42c44,46
>>> < ? ? (if (= (free-thread-counter thread-pool) (length (tasks thread-pool)))
>>> ---
>>>> ? ? (if (and (= (free-thread-counter thread-pool) (length (tasks
>>> thread-pool)))
>>>> ? ? ? ? ? ? ?(or (null (hard-limit thread-pool))
>>>> ? ? ? ? ? ? ? ? ?(< (length (threads thread-pool)) (hard-limit
>>> thread-pool))))
>>>
>>>
>>> _______________________________________________
>>> Eager-future-devel mailing list
>>> Eager-future-devel at common-lisp.net
>>> http://common-lisp.net/cgi-bin/mailman/listinfo/eager-future-devel
>>>
>>
>> _______________________________________________
>> Eager-future-devel mailing list
>> Eager-future-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/eager-future-devel
>



From wws at clozure.com  Sun Feb 21 17:00:58 2010
From: wws at clozure.com (Bill St. Clair)
Date: Sun, 21 Feb 2010 12:00:58 -0500
Subject: [Eager-future-devel] Hard-limit added to thread pool
In-Reply-To: <c07e645b1002202314r781e1e27q3398c68a3b3f3d7d@mail.gmail.com>
References: <4B71739D.5080408@clozure.com>	
	<c07e645b1002110222t2374b637rab6730542793a121@mail.gmail.com>	
	<4B73F516.9020706@clozure.com>
	<c07e645b1002202314r781e1e27q3398c68a3b3f3d7d@mail.gmail.com>
Message-ID: <4B8166CA.8050208@clozure.com>

Looks good. Thanks. And since the way you choose which thread pool to
use is with the binding of *thread-pool*, it remains very simple.

-Bill

On 2/21/10 2:14AM, Vladimir Sedach wrote:
> You're right, it does make more sense to put in some kind of thread
> pool open implementation mechanism than to try to build something on
> top of the one thread pool that eager future provides. I've pushed
> such a patch to the darcs repository; try it out.
> 
> Vladimir
> 
> 2010/2/11 Bill St. Clair <wws at clozure.com>:
>> On 2/11/10 5:22AM, Vladimir Sedach wrote:
>>> Hi Bill,
>>>
>>> The main reason I forked Eager Future from PCall is this behavior -
>>> the semantics of having SELECT multiplex on futures that are waiting
>>> on external events is very different when you can always guarantee
>>> that that future will get assigned to a thread vs. when you let it lie
>>> around in a queue. There's really no (easy/sane) way to guarantee any
>>> kind of fairness in the latter scenario. Note that your patch wouldn't
>>> even provide FIFO ordering for waiting tasks - the task list is a
>>> stack. The former approach assumes that the underlying thread
>>> implementation will be "reasonably fair" and everything will be
>>> alright.
>>
>> Understood.
>>
>>> Of course this leaves the burden of resource management to the
>>> application. The idea is that the application code can include a
>>> better approach to scheduling tasks than a PCall-style FIFO queue
>>> would provide.
>>
>> And one of those ways, which happens to work for my application, is to
>> use a PCall-style FIFO queue, which a few lines of code makes easy to
>> add to Eager-future. Note that it's not the default. Documentation could
>> warn of the potential problems with using it.
>>
>> Another possibility would be multiple thread pools with different
>> properties, the one like the presently implemented one being the
>> default, and optional parameters to pcall and friends to choose the pool
>> to use. Yes, that hairs up Eager-Future, which is now gloriously simple,
>> but that's the nature of the problem.
>>
>> -Bill
>>
>>> Vladimir
>>>
>>> 2010/2/9 Bill St. Clair <wws at clozure.com>:
>>>> I decided I wanted a way to put an upper-limit on the number of threads
>>>> created by the eager-future thread pool. Very simple change. Please
>>>> integrate it.
>>>>
>>>> -Bill St. Clair
>>>> wws at clozure.com
>>>>
>>>> $ darcs diff
>>>> diff -rN old-eager-future/package.lisp new-eager-future/package.lisp
>>>> 5c5,6
>>>> <            #:%thread-pool-soft-limit)
>>>> ---
>>>>>            #:%thread-pool-soft-limit
>>>>>            #:%thread-pool-hard-limit)
>>>> diff -rN old-eager-future/threads.lisp new-eager-future/threads.lisp
>>>> 6a7
>>>>>    (hard-limit :accessor hard-limit :initform nil)
>>>> 13a15
>>>>> (define-symbol-macro %thread-pool-hard-limit (hard-limit *thread-pool*))
>>>> 42c44,46
>>>> <     (if (= (free-thread-counter thread-pool) (length (tasks thread-pool)))
>>>> ---
>>>>>     (if (and (= (free-thread-counter thread-pool) (length (tasks
>>>> thread-pool)))
>>>>>              (or (null (hard-limit thread-pool))
>>>>>                  (< (length (threads thread-pool)) (hard-limit
>>>> thread-pool))))
>>>>
>>>>
>>>> _______________________________________________
>>>> Eager-future-devel mailing list
>>>> Eager-future-devel at common-lisp.net
>>>> http://common-lisp.net/cgi-bin/mailman/listinfo/eager-future-devel
>>>>
>>>
>>> _______________________________________________
>>> Eager-future-devel mailing list
>>> Eager-future-devel at common-lisp.net
>>> http://common-lisp.net/cgi-bin/mailman/listinfo/eager-future-devel
>>