The entire collective engineering effort for mod_perl and mod_apreq was to ensure our code was thread-safe, both from an httpd context and a Perl one. We achieved that twenty years ago, but have been stuck dealing with the fact that ithread engineering within Perl5 itself had a ways to go.
What I'm telling this list now is that Perl5 has finally caught up, and we can confidently tell you to familiarize yourself with the entire universe of tooling around ithread pools that is unique to mod_perl, and will blow you away once you are fully versed in how it can be tuned for maximum effect with minimal memory footprint. On Fri, Aug 26, 2022 at 1:49 PM Joe Schaefer <j...@sunstarsys.com> wrote: > Why are you still paying attention to mod_perl development, if you don't > even care to use it to full effect? > Running a 2-tiered webserver architecture is anathema to mod_perl. It's > not distinguishable from any other fastcgi thingy out there. > > > On Fri, Aug 26, 2022 at 1:46 PM John D Groenveld <groenv...@acm.org> > wrote: > >> In message <CAFQGv+Z-Ncmv3kajc41ag_6aid9= >> zhwww5d7fcmmcgpdmxs...@mail.gmail.com> >> , Joe Schaefer writes: >> >Lazy enough never to support HTTP/2? >> >> If HTTP/2 becomes necessary, my lazy first answer is to enable it in my >> mod_proxy front end. >> >> John >> groenv...@acm.org >> > > > -- > Joe Schaefer, Ph.D. > We only build what you need built. > <j...@sunstarsys.com> > 954.253.3732 <//954.253.3732> > > > -- Joe Schaefer, Ph.D. We only build what you need built. <j...@sunstarsys.com> 954.253.3732 <//954.253.3732>
