> > > hmmm...more thought, code reading, and whiteboard doodling is called
> > > for. Off the top of my head, I would think one of the config hooks in
> > > mod_status could allocate a big chuck of shmem for its use on every
> > > restart. Then the new worker processes would see the Right Stuff as far
> >
> > You can't allocate on every restart,
>
> sure we can, if we are careful about cleaning up
>
> > because if you do, the information
> > won't survive a restart. Imagine the pathological case, where a single
> > request is very long-lived, and it happens to survive multiple restarts.
> > If we reallocate during each restart, we will lose the status of that
> > request.
>
> good point...easily solved I think. "last guy out turns out the lights"
> - when the last process for generation x goes away, it's time to clean
> up generation x's huge chunk of shmem.
>
> >
> > > as pointers. The core should also allocate a new chunk of shmem to
> > > represent the processes at restart time, so we can get rid of the
> > > HARD_SERVER_LIMIT stuff (it's a PITA...think of admins in big shops who
> >
> > Again, you can't do that,
>
> understand your concern, but it just requires code.
You are talking about adding a lot of logic that has very little benefit
IMO. The purpose for these changes, are to remove HARD_SERVER_LIMIT, and
to make it easier to remove some shared memory if mod_status is not
loaded. How big a hardship is HARD_SERVER_LIMIT, and how much memory are
we really talking about?
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
