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

[Scott McKay]

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

> On Thu, Jun 3, 2010 at 21:52, Scott McKay <swm at itasoftware.com> wrote:
> 
>> On Jun 3, 2010, at 3:32 PM, Hans Hübner wrote:
> 
>>> 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.
> 
> I understand - Thanks for taking some extra time!  It'd be very nice
> if the thread pooling mechanism became generally useful and not
> require a lot of documentation describing its limitations.
> 

OK, I seem to have something useful working.  Note that the pooled-thread
taskmaster is still a stub, for two reasons:
 1. Thread creation is actually pretty damned fast (on Linux, anyway --
    around 200 microseconds on my box), and it's not clear that it's worth it.
 2. This *is* where Bordeaux Threads falls down, maybe because not all Lisp
    implementations support it.  "Restarting" an existing thread seems not
    to be a supported operation, so we'd need some complex -- and potentially
    fragile and error-prone -- protocol for doing "restartable" threads.

The other stuff now works, and there's a test suite for it all in QRes
(sadly, not in H'toot itself).