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

[Vladimir Sedach]

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
>