[Eager-future-devel] Hard-limit added to thread pool

[Bill St. Clair]

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
>>