On Jun 3, 2010, at 3:32 PM, Hans Hübner wrote:
On Thu, Jun 3, 2010 at 21:12, Scott McKay swm@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'.