I've been working on this more with some effort to get the number of connection threads to actually stay somewhere close to the range of minthreads to maxthreads.
But there was something a little more interesting to track down: what happens when a thread exits? I think there is some idea that the reason for exiting a thread is to remove memory leaks which might occur. But the question is, if threads are shared among servers, and threads exit on a number of connections, what else happens when the thread exits? Apparently, all the interps associated with the thread exit. I haven't seen any evidence against this conclusion. What this means is that thread exit is expensive. It could take down multiple interps (one for each server sharing the thread). This impacts the current discussion because I'm having trouble finding an easy way to avoid thread exit because of a timeout. But this information seems to simplify the problem. Why exit a thread just because of a timeout? I can't see any possible advantage. Instead, every effort should be directed at keeping threads alive until maxconns is reached. Also, shared threadpools should be limited to the default and error pools, otherwise a simple server could quickly expire interps of a more expensive server. tom jackson On Sunday 21 October 2007 14:47, Gustaf Neumann wrote: > Tom Jackson schrieb: > > The if statement on line 507 checks the Pool structure outside of a mutex > > lock. > > Good observation. > The code was not correct, although the potential damage was small. > Fixed by now. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
