I should clarify this comment. If maxthreads is set to zero after startup, as new requests are serviced, the thread will exit until all threads are gone. Since maxthreads is zero, no new threads will be created...but the driver thread still hands off requests which are never serviced. It should probably be illegal to set maxthreads to less than 1.
Maintaining at least minthreads could become difficult. I think you could consider it a bug, but maybe not. The result is this: your server will regulate threads down to the number required, a 'high water mark' less than or equal to maxthreads.
The best way to test this is to use something like apache bench. Set the concurrency above the minthreads and see if you can get it to go back over that amount. (Then let it rest and see threads exit, during testing you can set a low thread timeout.) Then set concurrency to something above maxthreads and see how it performs. You can test pages which are slow and see what happens. You will probably also need to keep pushing up the number of request to run (-n 500, or whatever), so that each thread gets multiple requests, and the queue gets a little full. You can also set the maxconnections to different values (very low and very high) and test that. Threads are started very quickly, but their startup cost is spread over maxconnections requests.
I'm guessing that what you will discover is that minthreads is a good hint at startup, but may be too many. If it is always too many, then you are wasting memory. Only by watching a production system can you determine a reasonable value for minthreads. If you have massive fluctuations in the number of requests over a time larger than thread timeout, then minthreads is pretty useless, you can expect it to drop below that soon after startup.
