[hunchentoot-devel] 'max-threads' behavior for Hunchentoot
Edi Weitz
edi at agharta.de
Sun Aug 22 19:36:13 UTC 2010
Faré, thanks for the patch which generally looks very good. However,
I just had to revert it because it breaks the LispWorks
implementation. I don't expect you to provide the new features for LW
as well, but at least on LW the code should still compile and load in
its old form - I'm relying on it for my daily work.
Also, I don't see the need for factoring out the version number in a
separate file.
Thanks,
Edi.
2010/8/21 Hans Hübner <hans.huebner at gmail.com>:
> Thanks Faré,
>
> I have committed the patch, minus the whitespace-only changes.
> Everyone, please give it a spin and report any errors that you may
> find.
>
> -Hans
>
> 2010/8/21 Faré <fahree at gmail.com>:
>> Dear Hunchentooters,
>>
>> here's my patch against the latest svn, de-xcvb-ified. That's what I'm
>> running at ITA, it seems to be passing the QRes precheckin. Can you
>> review, and apply if satisfactory?
>>
>> Suggested commit message (from Scott McKay's svn commit):
>>
>> Extend Hunchentoot's 'one-thread-per-connection-taskmaster'
>> to support 'max-threads' semantics, i.e., don't create
>> a new thread if we've max out.
>>
>> Add a 'pooled-thread-per-connection-taskmaster' that will
>> eventually use a thread pool, if profiling indicates.
>> Fix the 'handle-incoming-connection' to implement the
>> new behavior.
>> Add a commented-out implementation of 'accept-connections'
>> that might give better performance. This needs to be
>> discussed with the Hunchentoot maintainers.
>>
>> Address the review comments and discussions between Scott McKay
>> and Hans Huebner, who is one of the H'toot maintainers.
>> Also correctly issue HTTP 503 when the server runs out of threads.
>>
>> (work by Scott McKay)
>>
>> [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
>> Comparing oneself with Galileo or Einstein is certainly good for the ego —
>> provided one refrains from going into too much detail. — John McCarthy
>>
>
>
More information about the Tbnl-devel
mailing list