[hunchentoot-devel] 'max-threads' behavior for Hunchentoot

[Edi Weitz]

Buy me some time... :)

Nah, not really.  Sorry for the delay.  I've been busy recently and
just returned from a trip to New York.  I'll try to squeeze this in in
the next days.


On Mon, Sep 13, 2010 at 1:39 AM, Faré <fahree at gmail.com> wrote:
> Dear Edi,
>
> is there anything I can do to improve the patch that would help it
> make it to the official upstream hunchentoot?
>
> [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
> Any time you're asking the user to make a choice they don't care about,
> you have failed the user — Jeff Atwood
>
>
>
>
> On 24 August 2010 22:16, Faré <fahree at gmail.com> wrote:
>> Dear Edi,
>>
>> Here's a revised patch against the current svn. It's xcvb and version
>> changes reverted, otherwise what I'm running at ITA, and it seems to
>> be passing the QRes precheckin. It looks like it passes the elementary
>> test under Lispworks, but I don't personally have a working Lispworks
>> setup, so I can't say (will it work on LW Personal?).
>>
>> Can you review and apply if satisfactory?
>>
>>> Yes, the LispWorks version of Hunchentoot (which is the original
>>> Hunchentoot which only ran on LW) doesn't use any of the compatibility
>>> libs like BT, usocket, and cl+ssl.  I want it to stay that way - the
>>> less dependencies, the better.
>>>
>> Understood. I also saw that you defined trivial wrappers rather than
>> imported LW symbols, and kept things that way.
>>
>>> Can't you just comment out all the new stuff with #-:lispworks?  As I
>>> said, I'll take care of the LW version.
>>>
>> Scott did some work so it compiles under Lispworks, and
>> though it's wholly untested, I fixed it rather than scrapped it.
>> Please take it with a pinch of salt.
>>
>>
>> Suggested commit message:
>>
>>   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.
>>   Also correctly issue HTTP 503 when the server runs out of threads.
>>
>> (Work by Scott McKay, merge by François-René Rideau)
>>
>> [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
>> Moving parts in rubbing contact require lubrication to avoid excessive wear.
>> Honorifics and formal politeness provide lubrication where people rub together.
>> Often the very young, the untraveled, the naïve, the unsophisticated deplore
>> these formalities as "empty", "meaningless", or "dishonest", and scorn to use
>> them. No matter how "pure" their motives, they thereby throw sand into
>> machinery that does not work too well at best.
>>        — Robert Heinlein, "Time Enough For Love"
>>
>
>