Jeff Trawick wrote: > On 5/1/06, Greg Ames <[EMAIL PROTECTED]> wrote: > >> after more thought, there is a simpler patch that should do the job. the >> key to both of >> these is how threads in SERVER_DEAD state with a pid in the scoreboard are >> treated. this >> means that p_i_s_m forked on a previous timer pop but some thread never made >> it into >> SERVER_STARTING state. >> >> the difference: this patch just counts those potential threads as idle, and >> allows >> MinSpareThreads worth of processes to be forked before putting on the >> brakes. the >> previous patch pauses the forking immediately when the strange situation is >> detected but >> requires more code and a new variable. > > new patch is fine with me; I think we've lost our other interested > parties on this thread anyway ;)
I'm still here! I had to be away from the keyboard most of last week, so have only returned to this thread (pun intended, alas) recently. I also found myself fixing a variety of other things that turned up in the vicinity of this issue; patches forthcoming on those subjects. This is indeed a very straightforward fix; I've been trying to ponder its consequences overnight. The questions I've got (no answers yet, just thought I'd ping so you know I'm here) would be (a) whether you want to allow for SERVER_GRACEFUL as well to be counted as idle, and (b) whether there's any reason to want to not proceed through the if (any_dead_threads && ...) logic that follows in p_i_s_m(). If you can bear with me for a day or two more, I should have a collection of patches ready. These tackle the issue by tracking the start and listener threads in a nice new spot in the scoreboard, and also clean up various issues and bugs relating to fork(), ThreadLimit, ServerLimit, MaxClients, etc. They also tackle some issues raised in various XXX comments and clean up some stale cruft in scoreboard.h. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
