I have a v4.0.0 beta for sealed.pm that I expect will be fully operational
with mod_perl+ithreads now, but I will let it soak for a week to see what
happens in prod.
On Fri, Aug 26, 2022 at 3:30 PM Joe Schaefer wrote:
> You're welcome. Pardon my rudeness, but you will understand when I tell
> y
You're welcome. Pardon my rudeness, but you will understand when I tell
you that I developed sealed.pm after proving ithreads are solid on Solaris
over 2 years ago, and communicated with the Perl5 community on FB and LI
about the same thing I did here last week. There is considerable racism
and d
On Aug 26, 2022, at 1:16 PM, Joe Schaefer wrote:
> AFAICT you guys are just too lazy to look.
That came across as rude, Joe. Not all of us are experts at Perl internals or
track the latest changes to Perl's ithread support and/or glibc, and it's
generally been accepted in the mod_perl community
LOL IF YOU THINK THE WAIT FOR ITHREAD SUPPORT WAS A LONG TIME COMING.
https://github.com/majorz/apache2-rs/tree/master/src
On Fri, Aug 26, 2022 at 2:36 PM John D Groenveld wrote:
> In message <
> cafqgv+yb4bo3k4_hryccyj7ljsnejrh9hwyjw+9172ybc+q...@mail.gmail.com>
> , Joe Schaefer writes:
> >The
All of the zero-copy design elements of httpd are expanded on within
mod_perl in an ithread context.
All of those performance optimizations are lost when you bury them behind a
mod_proxy gateway to your application server running prefork.
Moreover, your scaling model for your application server is
In message
, Joe Schaefer writes:
>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
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'
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 wrot
In message
, 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
There isn't anything else on the market that will ever touch mod_perl +
mpm_event in terms of HTTP/2 performance.
And you don't need to ever spin up more ithreads than you have vCPU cores.
On Fri, Aug 26, 2022 at 1:36 PM Joe Schaefer wrote:
> Lazy enough never to support HTTP/2?
>
> On Fri, Aug
Lazy enough never to support HTTP/2?
On Fri, Aug 26, 2022 at 1:32 PM John D Groenveld wrote:
> In message <
> cafqgv+btwpyvvup2ewzfn7ruv4sfgdihadh48cm3n8qxpwb...@mail.gmail.com>
> , Joe Schaefer writes:
> >AFAICT you guys are just too lazy to look. Running latest on CPAN with an
>
> Correct.
> m
In message
, Joe Schaefer writes:
>AFAICT you guys are just too lazy to look. Running latest on CPAN with an
Correct.
mod_perl's make test mostly passes and does not core with mpm_event under
OmniOS/illumos, FreeBSD, and Void Linux with Musl, but I haven't tested
my applications because I am lazy
AFAICT you guys are just too lazy to look. Running latest on CPAN with an
Ubuntu 22.04 stock httpd and the thing just cranks out the hits.
(Not with sealed.pm tho, it will leak scalars and cause crashes with
mod_perl and mpm_event).
If anybody is to thank for this, thank SawyerX for his Pumpking w
13 matches
Mail list logo
