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

[Scott McKay]

On Jun 3, 2010, at 3:32 PM, Hans Hübner wrote:

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

By the way, this is seeming rather beyond the scope of the
original patch.  I'll spend another day on this, but I really
can't justify spending too much longer on it -- even though
it's fun.

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

My mistake!  There is 'condition-wait' and 'condition-notify'.