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

[Hans Hübner]

On Thu, Jun 3, 2010 at 21:12, Scott McKay <swm at itasoftware.com> wrote:
> On Jun 2, 2010, at 2:25 AM, Hans Hübner wrote:

>> There should be two configurable modes as to how Hunchentoot handles
>> an incoming connection when no handler thread is available:  One would
>> set up things so that the connection is accepted, but a 503 error is
>> sent out right away.  The other would suspend accepting connections
>> until a thread is available.  The latter mode would make new clients
>> hang (and, if the listener queue runs full, be rejected) until
>> resources are available again.
>>
>
> The latter is a nice idea, but I have no good idea how to
> implement it portably, given the very limited thread model
> provided by Bordeaux Threads.

One possible approach would be:  When the acceptor detects that there
is a resource shortage, it waits on a synchronization variable until a
thread in the pool is freed instead of looping to the next accept.
The wait should be periodically interrupted to check for server
shutdown.  I believe that this should be relatively straightforward,
although it may need some refactoring in the ACCEPT-CONNECTIONS
generic function.  Maybe it makes sense to add a new generic function
ACCEPT-NEXT-CONNECTION that could have an :AROUND method for your
pooled acceptor class which would wait for a thread to be available
before calling the next method.

What do you mean by the limited thread model of BT, how does it hurt?

-Hans