My observation was that that the mapped pages for 2-6 fundamental socache, lbmethod or slotmem providers are the same as for a single module due to page alignment - load any two and you are already wasting kernel resources and memory.
I agree that any user agent or content facing modules should remain distinct - only load those you use and trust. These core feature sets, when used, only face the conf file or in the case of lbmethod, the admin console. So they should be safe to load in parallel, when leveraged for a given module. They should even be safe to compile static, if the user likes. On Dec 4, 2015 07:33, "Jim Jagielski" <j...@jagunet.com> wrote: > I thought the idea of providers and submodules were so > that, for example, if someone only used byrequests, for > example, they only needed to build and load that specific > submodule and nothing else... Not seeing what issue exactly > you're trying to address. > > > On Dec 3, 2015, at 6:25 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > > > On Thu, Dec 3, 2015 at 3:40 PM, Jim Jagielski <j...@jagunet.com> wrote: > > > > > On Dec 3, 2015, at 11:09 AM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > > > > > My personal wish list is that we eliminate module bloat by coalescing > > > alternative "standard" implementations into a single module again in > > > 2.next, and not just limited to lbmethod, but also the core socache > > > and slotmem providers. Most stock/core implementations shouldn't > > > change if a user wants to plug in 'yet another' option, but there is > really > > > no excuse for us to map so many ldobjects and text pages into the > > > memory map of a given process, when the actual program text page > > > of each is a few hundred opcodes, max. > > > > > > > Not following you there... what do you mean? You mention the > > lbmethods; do you mean instead of having each method be its > > own module, making them all one? > > > > Not specific to lbmethods but yes, one mod_lbmethod_core.so provider > > of the basic set of 3-4 methods that right now eat up a lot of 64kb > process > > page mappings for no particular benefit. The builder could even decide > these > > are compiled-in to the base httpd. We don't dismiss the loadable > approach, > > we simply decide this subset is effectively baked, and then use the > loadable > > lbmethod to extend yet another experimental/dynamic/evolving method, from > > the ASF or third parties. > > > > > >
