[hunchentoot-devel] Hunchentoot and threads

[Cyrus Harmon]

I seem to recall that, a long time ago, TBNL/hunchentoot required  
threads. At some point Edi rigged up a singled threaded version but  
claimed that that was just for development/testing work and shouldn't  
be used in the real world. Now I understand that Hans has an aversion  
to threads as the multiplexing abstraction for webservers and that  
single threaded is "the one true way." I bring this up as background  
to me real problem, which is that, at least on FreeBSD, I seem to have  
a number of zombie threads that stick around after requests are made.  
Before I dig into the problem, I'd be curious to hear what folks'  
recommendations for running a low-traffic, but nevertheless hopefully  
reliable, site are. I had reasonably good luck with SBCL+threads and  
hunchentoot before the big rewrite, but since then, it has been  
reliable refusing to accept new connections after a week or two of use.

Everything starts out fine and I can field some traffic and all is good:

CL-USER> (sb-thread:list-all-threads)
(#<SB-THREAD:THREAD "reader-thread" RUNNING {59B6B241}>
  #<SB-THREAD:THREAD "repl-thread" RUNNING {59B6B0F1}>
  #<SB-THREAD:THREAD "control-thread" RUNNING {59B60359}>
  #<SB-THREAD:THREAD "auto-flush-thread" RUNNING {59B601D9}>
  #<SB-THREAD:THREAD "initial thread" RUNNING {598D79B1}>)

However, after some period, I see an accumulation of worker threads  
that won't die and eventually I'm unable to start a new thread to  
field the request. Who knows where the problem is... Could be in  
hunchentoot proper, in usocket, in SBCL's FreeBSD threads, etc... At  
the moment I don't have any debugging info on the problem, as all  
seems to be working ok since I restarted the web server a few minutes  
ago. The next time the problem crops up, I'll reply to this with some  
debugging information. This seems to be the one major "regression"  
from the old hunchentoot that has me considering going back to the  
stable release (although I've already ported my code forward for the  
new API, so I'd hate to have to do that). Better yet would be to  
either track down and fix the problem or to be convinced that this is  
just broken and is never going to work and figure out how to make my  
stuff work in a single threaded lisp.

One more question regarding threads, is it possible to use a threaded  
lisp to act like the single threaded server does? That is to use  
threads, but to only have one thread doing the hard work, using serve- 
event for the multiplexing? My initialization code relies on setting  
some state after starting to listen for requests, so I can't just flip  
the switch to single-threaded mode and have everything work out of the  
box.

Thanks for all of the hunchentoot rewrite efforts! On the whole it  
seems like a good thing, but fixing this issue would make me a much  
happier hunchentoot user.

Cyrus