[Bese-devel] Threadpooling in multithread-httpd-backend

Nathan Bird nathan at acceleration.net
Tue Nov 22 17:54:46 UTC 2005


From: bese-devel-bounces at common-lisp.net
[mailto:bese-devel-bounces at common-lisp.net] On Behalf Of Nathan Bird
Sent: Friday, November 11, 2005 11:27 AM
To: bese-devel at common-lisp.net
Subject: [Bese-devel] Threadpooling in multithread-httpd-backend

>By default it creates 4 workers when it starts and has a max worker count
>of 32.  Right now when it exceeds max workers it re-queues the connection
>message to the control thread hoping one of the other workers finishes off
>in the meantime. This probably isn’t the best strategy. What happens if a
>worker never becomes available? Can we check to see if the client is still
>connected before re-queuing or something?

We (Russ and I) have changed it a bit. An incoming request now gets a
timestamp. When there are no workers available, if the timestamp is not to
old then the request is re-queued to the control thread, if it is to old it
is simply abandoned.

>I’ve tested this with SBCL 0.9.5 on linux with mod_lisp and it seems to
>work there, but overall this patch should probably be considered unstable.

Same again.


We also tried to do a bit better error-handling in the control loop since
there is now more code being run there. Hooking into *debug-on-error*,
invoking the debugger where appropriate and just logging and ignoring the
error if *debug-on-error* is nil.


Nathan Bird




More information about the bese-devel mailing list