DRAKMA: [singing] ...Yes, YOU'RE ALL REAL COOL, with those little WEBS you SPOOL and all your 'SPIDER DROOL'... Oh! Let me float in your pool!
HUNCHENTOOT: [disgruntled] "What you want NOW, bitch?"
--
GORDON: [ambitiously hacking] I'd like to have two settings in Hunchentoot to control the maximum number of worker threads, and how many connections are accepted (and queued) for processing when the maximum is exceeded. If the maximum is exceeded, new connection attempts should be refused. This is analogous to Tomcat's maxThreads and acceptCount settings. It could be implemented by a pool of worker threads. Is this a concept that anybody has experimented yet with current version of Hunchentoot? Are there any thoughts about how a thread pool should work, especially the coordination (or division of responsibility) between ACCEPTOR and TASKMASTER objects? Any portability concerns?
thanks, -Gordon
Hi Gordon,
On Sat, May 15, 2010 at 14:53, Gordon Sims gordon@itasoftware.com wrote:
GORDON: [ambitiously hacking] I'd like to have two settings in Hunchentoot to control the maximum number of worker threads, and how many connections are accepted (and queued) for processing when the maximum is exceeded. If the maximum is exceeded, new connection attempts should be refused. This is analogous to Tomcat's maxThreads and acceptCount settings. It could be implemented by a pool of worker threads. Is this a concept that anybody has experimented yet with current version of Hunchentoot? Are there any thoughts about how a thread pool should work, especially the coordination (or division of responsibility) between ACCEPTOR and TASKMASTER objects? Any portability concerns?
I can't really give you good advice, but the ACCEPTOR and TASKMASTER classes have been invented to support thread pooling in addition to the single threaded TASKMASTER subclass. It would be great to have a thread pooling implementation in the base code, presumably based on BORDEAUX-THREADS.
Let's see some code :)
-Hans
-
Gordon Sims -
Hans Hübner