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

Scott McKay swm at itasoftware.com
Thu Jun 3 20:58:51 UTC 2010


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

Yep, I'm working on this now.  It doesn't look like I'll
need to do any refactoring, but I'm not sure how to get
'condition-wait' to let itself be interrupted to poll for
server shutdowns...





More information about the Tbnl-devel mailing list