Jeff Trawick wrote: > > [EMAIL PROTECTED] writes: > > > Log: > > Change core code to allow an MPM to set hard thread/server > > limits at startup.
++1. Thanks for doing this work, Jeff. It always seemed wrong that we had to recompile http_protocol.c whenever we changed the scoreboard geometry. > > + > > +/* we only ever have 1 main process running... */ > > +#define HARD_SERVER_LIMIT 1 > > + > > +/* Limit on the threads per process. Clients will be locked out if more than > > + * this * HARD_SERVER_LIMIT are needed. > > + * > > + * We keep this for one reason it keeps the size of the scoreboard file small > > + * enough that we can read the whole thing without worrying too much about > > + * the overhead. > > + */ > > +#ifdef NO_THREADS > > +#define HARD_THREAD_LIMIT 1 > > +#endif > > +#ifndef HARD_THREAD_LIMIT > > +#define HARD_THREAD_LIMIT 50 > > +#endif > > Hmmm... (2nd thoughts :) ) > > mpm_default.h exists so people can edit default settings in one nice > place... it wasn't nice for me to move these things out of > mpm_defaults.h... I'll move them back in there... hopefully these > settings won't be abused by modules and instead modules will call > ap_mpm_query() I wouldn't move them back. If you keep them out of the header file, modules will have to use to use the MPM query functions, which is goodness. Once we decide how to configure the limits for worker and perchild, we can just use a subset of that stuff to set limits for the other MPMs. Prefork doesn't have the same potential memory consumption problem as worker, but it's still a pain to have to patch HARD_SERVER_LIMIT every time we put a new build on daedalus. I would think the same applies to Win32 and OS/2 with the current hard thread limits. Of course we don't want admins editing .c files as a rule. That would be a step backwards. But if our goal is to put these params in the config file, we can live with the limits in the MPM .c files for a day or two. Greg
