Re: sealed.pm v4.0.0 is out
Take a walk down history lane with me here:
https://www.perl.com/pub/2000/06/dougpatch.html/
Like ithreads, the idea was sparked from Gurusamy's genius, coded up by
Doug, and largely forgotten by p5p politics.
It's not that it couldn't be done, they arrived at the place where it
*shouldn't* be done, which was deflating for mod_perl fans.
Simon Couzens made a lot of inroads since, with modularized Perl compilers
and B::Generate, but it wasn't until
Perl7 that I was motivated to try any way forward, on a more limited,
controllable scale.
What do you think? How should this piece of the mod_perl puzzle fit in to
the CPAN universe?
On Tue, Aug 30, 2022 at 2:12 PM Joe Schaefer wrote:
> Every method call that's implemented in XS is looked-up at compile-time in
> that script, even for class methods.
> That's the sweet spot for :sealed. The only other things I do with it are
> a few hot methods in Dotiac::DTL::Core, but that's probably not worth the
> bother.
>
> On Tue, Aug 30, 2022 at 1:14 PM Joe Schaefer wrote:
>
>> Just look through my commit history on this sample Registry script to see
>> what's involved in getting sealed activated on your scripts.
>>
>> https://github.com/SunStarSys/cms/blob/master/enquiry.pl
>>
>> On Tue, Aug 30, 2022 at 1:12 PM Joe Schaefer wrote:
>>
>>> It'd be pretty harmless to apply the RegistryCooker.pm patch once we
>>> find a home for sealed.pm (either in this project or as a stand-alone
>>> pragma on CPAN).
>>> Nothing will segfault without consciously using types on your lexical
>>> object reference declarations; otherwise it's a giant noop.
>>>
>>> On Tue, Aug 30, 2022 at 12:53 PM Joe Schaefer
>>> wrote:
>>>
If you really beat the hell out of it thread-wise, sealed.pm v4.0.0
will still segfault, but there's not much more I can do with the code at
this point to prevent that.
B::Generate doesn't really support what I'm doing here, which is to do
surgery on an existing op-tree, instead of just playing around with a
user-generated one.
There's no good way to remove the target "method_named" op that we're
replacing with a gv_op. If that can't be supported using B::OP APIs, then
it should
be handled from perl itself. The problem is that the politics around
the feature were never resolved, because nobody wants to change the default
"virtual method"
behavior of Perl's OO-runtime-lookups. Now with the new :sealed
SUBROUTINE ATTRIBUTE, it's only enabled for people (like us) who want it
conditionally applied,
just like we do for the :method attribute.
On Tue, Aug 30, 2022 at 11:26 AM Joe Schaefer
wrote:
> Someday this patch might be interesting:
>
> diff -u RegistryCooker.pm~ RegistryCooker.pm
> --- RegistryCooker.pm~ 2022-08-30 11:10:19.790171019 -0400
> +++ RegistryCooker.pm 2022-08-30 11:12:34.319572045 -0400
> @@ -399,7 +399,8 @@
> my $eval = join '',
> 'package ',
> $self->{PACKAGE}, ";",
> -"sub handler {",
> +"use base 'sealed';",
> +"sub handler :Sealed {",
> "local \$0 = '$script_name';",
> $nph,
> $shebang,
>
> On Mon, Aug 29, 2022 at 2:21 PM Joe Schaefer
> wrote:
>
>> Forgive me for the pent up frustration of having our wonderful
>> mod_perl project being completely ignored and abandoned by the Perl
>> Steering Committee's frivolous lingustic interests over the years since
>> the
>> Parrot announcement.
>> SaywerX gave us a reason to be hopeful again. Let's see what they do
>> with it.
>>
>> On Mon, Aug 29, 2022 at 1:34 PM Joe Schaefer
>> wrote:
>>
>>> If the Perl steering committee had any brains left it would have
>>> capitalized on the perl 5.34 release and Co announced modperl2 ithread
>>> compatibility now available with Perl7’s new release.
>>>
>>> Instead they are going to kick the tires on the defaults for
>>> strictures and warnings until nobody cares any more.
>>>
>>> Get Outlook for iOS
>>> --
>>> *From:* Joe Schaefer
>>> *Sent:* Monday, August 29, 2022 1:17:17 PM
>>> *To:* mod_perl list
>>> *Subject:* Re: sealed.pm v4.0.0 is out
>>>
>>> The only reason I’ve been vacillating about glibc/malloc thread
>>> safety is because I couldn’t fathom the fact that people still believed
>>> modperl isn’t compatible with mpm_event at this point in the Perl7
>>> storyline. The old segfaults of the past that happened in glibc malloc
>>> were because Perl was corrupting the heap in some other part of the
>>> codebase, and there’s no simple way to track it down without a tool like
>>> Valgrind, but we weren’t successful with that effort either.
Re: sealed.pm v4.0.0 is out
Every method call that's implemented in XS is looked-up at compile-time in
that script, even for class methods.
That's the sweet spot for :sealed. The only other things I do with it are
a few hot methods in Dotiac::DTL::Core, but that's probably not worth the
bother.
On Tue, Aug 30, 2022 at 1:14 PM Joe Schaefer wrote:
> Just look through my commit history on this sample Registry script to see
> what's involved in getting sealed activated on your scripts.
>
> https://github.com/SunStarSys/cms/blob/master/enquiry.pl
>
> On Tue, Aug 30, 2022 at 1:12 PM Joe Schaefer wrote:
>
>> It'd be pretty harmless to apply the RegistryCooker.pm patch once we find
>> a home for sealed.pm (either in this project or as a stand-alone pragma
>> on CPAN).
>> Nothing will segfault without consciously using types on your lexical
>> object reference declarations; otherwise it's a giant noop.
>>
>> On Tue, Aug 30, 2022 at 12:53 PM Joe Schaefer wrote:
>>
>>> If you really beat the hell out of it thread-wise, sealed.pm v4.0.0
>>> will still segfault, but there's not much more I can do with the code at
>>> this point to prevent that.
>>> B::Generate doesn't really support what I'm doing here, which is to do
>>> surgery on an existing op-tree, instead of just playing around with a
>>> user-generated one.
>>> There's no good way to remove the target "method_named" op that we're
>>> replacing with a gv_op. If that can't be supported using B::OP APIs, then
>>> it should
>>> be handled from perl itself. The problem is that the politics around
>>> the feature were never resolved, because nobody wants to change the default
>>> "virtual method"
>>> behavior of Perl's OO-runtime-lookups. Now with the new :sealed
>>> SUBROUTINE ATTRIBUTE, it's only enabled for people (like us) who want it
>>> conditionally applied,
>>> just like we do for the :method attribute.
>>>
>>> On Tue, Aug 30, 2022 at 11:26 AM Joe Schaefer
>>> wrote:
>>>
Someday this patch might be interesting:
diff -u RegistryCooker.pm~ RegistryCooker.pm
--- RegistryCooker.pm~ 2022-08-30 11:10:19.790171019 -0400
+++ RegistryCooker.pm 2022-08-30 11:12:34.319572045 -0400
@@ -399,7 +399,8 @@
my $eval = join '',
'package ',
$self->{PACKAGE}, ";",
-"sub handler {",
+"use base 'sealed';",
+"sub handler :Sealed {",
"local \$0 = '$script_name';",
$nph,
$shebang,
On Mon, Aug 29, 2022 at 2:21 PM Joe Schaefer
wrote:
> Forgive me for the pent up frustration of having our wonderful
> mod_perl project being completely ignored and abandoned by the Perl
> Steering Committee's frivolous lingustic interests over the years since
> the
> Parrot announcement.
> SaywerX gave us a reason to be hopeful again. Let's see what they do
> with it.
>
> On Mon, Aug 29, 2022 at 1:34 PM Joe Schaefer
> wrote:
>
>> If the Perl steering committee had any brains left it would have
>> capitalized on the perl 5.34 release and Co announced modperl2 ithread
>> compatibility now available with Perl7’s new release.
>>
>> Instead they are going to kick the tires on the defaults for
>> strictures and warnings until nobody cares any more.
>>
>> Get Outlook for iOS
>> --
>> *From:* Joe Schaefer
>> *Sent:* Monday, August 29, 2022 1:17:17 PM
>> *To:* mod_perl list
>> *Subject:* Re: sealed.pm v4.0.0 is out
>>
>> The only reason I’ve been vacillating about glibc/malloc thread
>> safety is because I couldn’t fathom the fact that people still believed
>> modperl isn’t compatible with mpm_event at this point in the Perl7
>> storyline. The old segfaults of the past that happened in glibc malloc
>> were because Perl was corrupting the heap in some other part of the
>> codebase, and there’s no simple way to track it down without a tool like
>> Valgrind, but we weren’t successful with that effort either.
>>
>> Get Outlook for iOS
>> --
>> *From:* Joe Schaefer
>> *Sent:* Monday, August 29, 2022 1:08:00 PM
>> *To:* mod_perl list
>> *Subject:* Re: sealed.pm v4.0.0 is out
>>
>> Religiously avoid setting up per request ithread environment
>> variables. Just use PerlSetEnv in your Webserver config. Everything we
>> did
>> in modperl to support CGI scripts is a train wreck.
>>
>> Get Outlook for iOS
>> --
>> *From:* Joe Schaefer
>> *Sent:* Monday, August 29, 2022 1:04:03 PM
>> *To:* mod_perl list
>> *Subject:* Re: sealed.pm v4.0.0 is out
>>
>> Look into reducing the scope of your interpreters down from
Re: sealed.pm v4.0.0 is out
Just look through my commit history on this sample Registry script to see
what's involved in getting sealed activated on your scripts.
https://github.com/SunStarSys/cms/blob/master/enquiry.pl
On Tue, Aug 30, 2022 at 1:12 PM Joe Schaefer wrote:
> It'd be pretty harmless to apply the RegistryCooker.pm patch once we find
> a home for sealed.pm (either in this project or as a stand-alone pragma
> on CPAN).
> Nothing will segfault without consciously using types on your lexical
> object reference declarations; otherwise it's a giant noop.
>
> On Tue, Aug 30, 2022 at 12:53 PM Joe Schaefer wrote:
>
>> If you really beat the hell out of it thread-wise, sealed.pm v4.0.0 will
>> still segfault, but there's not much more I can do with the code at this
>> point to prevent that.
>> B::Generate doesn't really support what I'm doing here, which is to do
>> surgery on an existing op-tree, instead of just playing around with a
>> user-generated one.
>> There's no good way to remove the target "method_named" op that we're
>> replacing with a gv_op. If that can't be supported using B::OP APIs, then
>> it should
>> be handled from perl itself. The problem is that the politics around the
>> feature were never resolved, because nobody wants to change the default
>> "virtual method"
>> behavior of Perl's OO-runtime-lookups. Now with the new :sealed
>> SUBROUTINE ATTRIBUTE, it's only enabled for people (like us) who want it
>> conditionally applied,
>> just like we do for the :method attribute.
>>
>> On Tue, Aug 30, 2022 at 11:26 AM Joe Schaefer wrote:
>>
>>> Someday this patch might be interesting:
>>>
>>> diff -u RegistryCooker.pm~ RegistryCooker.pm
>>> --- RegistryCooker.pm~ 2022-08-30 11:10:19.790171019 -0400
>>> +++ RegistryCooker.pm 2022-08-30 11:12:34.319572045 -0400
>>> @@ -399,7 +399,8 @@
>>> my $eval = join '',
>>> 'package ',
>>> $self->{PACKAGE}, ";",
>>> -"sub handler {",
>>> +"use base 'sealed';",
>>> +"sub handler :Sealed {",
>>> "local \$0 = '$script_name';",
>>> $nph,
>>> $shebang,
>>>
>>> On Mon, Aug 29, 2022 at 2:21 PM Joe Schaefer wrote:
>>>
Forgive me for the pent up frustration of having our wonderful mod_perl
project being completely ignored and abandoned by the Perl Steering
Committee's frivolous lingustic interests over the years since the Parrot
announcement.
SaywerX gave us a reason to be hopeful again. Let's see what they do
with it.
On Mon, Aug 29, 2022 at 1:34 PM Joe Schaefer
wrote:
> If the Perl steering committee had any brains left it would have
> capitalized on the perl 5.34 release and Co announced modperl2 ithread
> compatibility now available with Perl7’s new release.
>
> Instead they are going to kick the tires on the defaults for
> strictures and warnings until nobody cares any more.
>
> Get Outlook for iOS
> --
> *From:* Joe Schaefer
> *Sent:* Monday, August 29, 2022 1:17:17 PM
> *To:* mod_perl list
> *Subject:* Re: sealed.pm v4.0.0 is out
>
> The only reason I’ve been vacillating about glibc/malloc thread safety
> is because I couldn’t fathom the fact that people still believed modperl
> isn’t compatible with mpm_event at this point in the Perl7 storyline. The
> old segfaults of the past that happened in glibc malloc were because Perl
> was corrupting the heap in some other part of the codebase, and there’s no
> simple way to track it down without a tool like Valgrind, but we weren’t
> successful with that effort either.
>
> Get Outlook for iOS
> --
> *From:* Joe Schaefer
> *Sent:* Monday, August 29, 2022 1:08:00 PM
> *To:* mod_perl list
> *Subject:* Re: sealed.pm v4.0.0 is out
>
> Religiously avoid setting up per request ithread environment
> variables. Just use PerlSetEnv in your Webserver config. Everything we did
> in modperl to support CGI scripts is a train wreck.
>
> Get Outlook for iOS
> --
> *From:* Joe Schaefer
> *Sent:* Monday, August 29, 2022 1:04:03 PM
> *To:* mod_perl list
> *Subject:* Re: sealed.pm v4.0.0 is out
>
> Look into reducing the scope of your interpreters down from the
> request level to the handler level. If all you are doing is running
> registry scripts, you will get even better scaling out of just a few
> ithreads per worker process.
>
> Get Outlook for iOS
> --
> *From:* Joe Schaefer
> *Sent:* Monday, August 29, 2022 12:57:14 PM
> *To:* mod_perl list
> *Subject:* Re: sealed.pm v4.0.0 is out
>
> The only
Re: sealed.pm v4.0.0 is out
It'd be pretty harmless to apply the RegistryCooker.pm patch once we find a
home for sealed.pm (either in this project or as a stand-alone pragma on
CPAN).
Nothing will segfault without consciously using types on your lexical
object reference declarations; otherwise it's a giant noop.
On Tue, Aug 30, 2022 at 12:53 PM Joe Schaefer wrote:
> If you really beat the hell out of it thread-wise, sealed.pm v4.0.0 will
> still segfault, but there's not much more I can do with the code at this
> point to prevent that.
> B::Generate doesn't really support what I'm doing here, which is to do
> surgery on an existing op-tree, instead of just playing around with a
> user-generated one.
> There's no good way to remove the target "method_named" op that we're
> replacing with a gv_op. If that can't be supported using B::OP APIs, then
> it should
> be handled from perl itself. The problem is that the politics around the
> feature were never resolved, because nobody wants to change the default
> "virtual method"
> behavior of Perl's OO-runtime-lookups. Now with the new :sealed
> SUBROUTINE ATTRIBUTE, it's only enabled for people (like us) who want it
> conditionally applied,
> just like we do for the :method attribute.
>
> On Tue, Aug 30, 2022 at 11:26 AM Joe Schaefer wrote:
>
>> Someday this patch might be interesting:
>>
>> diff -u RegistryCooker.pm~ RegistryCooker.pm
>> --- RegistryCooker.pm~ 2022-08-30 11:10:19.790171019 -0400
>> +++ RegistryCooker.pm 2022-08-30 11:12:34.319572045 -0400
>> @@ -399,7 +399,8 @@
>> my $eval = join '',
>> 'package ',
>> $self->{PACKAGE}, ";",
>> -"sub handler {",
>> +"use base 'sealed';",
>> +"sub handler :Sealed {",
>> "local \$0 = '$script_name';",
>> $nph,
>> $shebang,
>>
>> On Mon, Aug 29, 2022 at 2:21 PM Joe Schaefer wrote:
>>
>>> Forgive me for the pent up frustration of having our wonderful mod_perl
>>> project being completely ignored and abandoned by the Perl Steering
>>> Committee's frivolous lingustic interests over the years since the Parrot
>>> announcement.
>>> SaywerX gave us a reason to be hopeful again. Let's see what they do
>>> with it.
>>>
>>> On Mon, Aug 29, 2022 at 1:34 PM Joe Schaefer wrote:
>>>
If the Perl steering committee had any brains left it would have
capitalized on the perl 5.34 release and Co announced modperl2 ithread
compatibility now available with Perl7’s new release.
Instead they are going to kick the tires on the defaults for strictures
and warnings until nobody cares any more.
Get Outlook for iOS
--
*From:* Joe Schaefer
*Sent:* Monday, August 29, 2022 1:17:17 PM
*To:* mod_perl list
*Subject:* Re: sealed.pm v4.0.0 is out
The only reason I’ve been vacillating about glibc/malloc thread safety
is because I couldn’t fathom the fact that people still believed modperl
isn’t compatible with mpm_event at this point in the Perl7 storyline. The
old segfaults of the past that happened in glibc malloc were because Perl
was corrupting the heap in some other part of the codebase, and there’s no
simple way to track it down without a tool like Valgrind, but we weren’t
successful with that effort either.
Get Outlook for iOS
--
*From:* Joe Schaefer
*Sent:* Monday, August 29, 2022 1:08:00 PM
*To:* mod_perl list
*Subject:* Re: sealed.pm v4.0.0 is out
Religiously avoid setting up per request ithread environment variables.
Just use PerlSetEnv in your Webserver config. Everything we did in modperl
to support CGI scripts is a train wreck.
Get Outlook for iOS
--
*From:* Joe Schaefer
*Sent:* Monday, August 29, 2022 1:04:03 PM
*To:* mod_perl list
*Subject:* Re: sealed.pm v4.0.0 is out
Look into reducing the scope of your interpreters down from the request
level to the handler level. If all you are doing is running registry
scripts, you will get even better scaling out of just a few ithreads per
worker process.
Get Outlook for iOS
--
*From:* Joe Schaefer
*Sent:* Monday, August 29, 2022 12:57:14 PM
*To:* mod_perl list
*Subject:* Re: sealed.pm v4.0.0 is out
The only impact to your work with modperl is that you will need to
assess the ithread-safety of your dependent XS-based modules. For example,
use a JSON::XS thread safe alternative- there are several.
Get Outlook for iOS
--
*From:* Joe Schaefer
*Sent:* Monday, August 29, 2022 12:49:22 PM
Re: sealed.pm v4.0.0 is out
If you really beat the hell out of it thread-wise, sealed.pm v4.0.0 will
still segfault, but there's not much more I can do with the code at this
point to prevent that.
B::Generate doesn't really support what I'm doing here, which is to do
surgery on an existing op-tree, instead of just playing around with a
user-generated one.
There's no good way to remove the target "method_named" op that we're
replacing with a gv_op. If that can't be supported using B::OP APIs, then
it should
be handled from perl itself. The problem is that the politics around the
feature were never resolved, because nobody wants to change the default
"virtual method"
behavior of Perl's OO-runtime-lookups. Now with the new :sealed SUBROUTINE
ATTRIBUTE, it's only enabled for people (like us) who want it conditionally
applied,
just like we do for the :method attribute.
On Tue, Aug 30, 2022 at 11:26 AM Joe Schaefer wrote:
> Someday this patch might be interesting:
>
> diff -u RegistryCooker.pm~ RegistryCooker.pm
> --- RegistryCooker.pm~ 2022-08-30 11:10:19.790171019 -0400
> +++ RegistryCooker.pm 2022-08-30 11:12:34.319572045 -0400
> @@ -399,7 +399,8 @@
> my $eval = join '',
> 'package ',
> $self->{PACKAGE}, ";",
> -"sub handler {",
> +"use base 'sealed';",
> +"sub handler :Sealed {",
> "local \$0 = '$script_name';",
> $nph,
> $shebang,
>
> On Mon, Aug 29, 2022 at 2:21 PM Joe Schaefer wrote:
>
>> Forgive me for the pent up frustration of having our wonderful mod_perl
>> project being completely ignored and abandoned by the Perl Steering
>> Committee's frivolous lingustic interests over the years since the Parrot
>> announcement.
>> SaywerX gave us a reason to be hopeful again. Let's see what they do
>> with it.
>>
>> On Mon, Aug 29, 2022 at 1:34 PM Joe Schaefer wrote:
>>
>>> If the Perl steering committee had any brains left it would have
>>> capitalized on the perl 5.34 release and Co announced modperl2 ithread
>>> compatibility now available with Perl7’s new release.
>>>
>>> Instead they are going to kick the tires on the defaults for strictures
>>> and warnings until nobody cares any more.
>>>
>>> Get Outlook for iOS
>>> --
>>> *From:* Joe Schaefer
>>> *Sent:* Monday, August 29, 2022 1:17:17 PM
>>> *To:* mod_perl list
>>> *Subject:* Re: sealed.pm v4.0.0 is out
>>>
>>> The only reason I’ve been vacillating about glibc/malloc thread safety
>>> is because I couldn’t fathom the fact that people still believed modperl
>>> isn’t compatible with mpm_event at this point in the Perl7 storyline. The
>>> old segfaults of the past that happened in glibc malloc were because Perl
>>> was corrupting the heap in some other part of the codebase, and there’s no
>>> simple way to track it down without a tool like Valgrind, but we weren’t
>>> successful with that effort either.
>>>
>>> Get Outlook for iOS
>>> --
>>> *From:* Joe Schaefer
>>> *Sent:* Monday, August 29, 2022 1:08:00 PM
>>> *To:* mod_perl list
>>> *Subject:* Re: sealed.pm v4.0.0 is out
>>>
>>> Religiously avoid setting up per request ithread environment variables.
>>> Just use PerlSetEnv in your Webserver config. Everything we did in modperl
>>> to support CGI scripts is a train wreck.
>>>
>>> Get Outlook for iOS
>>> --
>>> *From:* Joe Schaefer
>>> *Sent:* Monday, August 29, 2022 1:04:03 PM
>>> *To:* mod_perl list
>>> *Subject:* Re: sealed.pm v4.0.0 is out
>>>
>>> Look into reducing the scope of your interpreters down from the request
>>> level to the handler level. If all you are doing is running registry
>>> scripts, you will get even better scaling out of just a few ithreads per
>>> worker process.
>>>
>>> Get Outlook for iOS
>>> --
>>> *From:* Joe Schaefer
>>> *Sent:* Monday, August 29, 2022 12:57:14 PM
>>> *To:* mod_perl list
>>> *Subject:* Re: sealed.pm v4.0.0 is out
>>>
>>> The only impact to your work with modperl is that you will need to
>>> assess the ithread-safety of your dependent XS-based modules. For example,
>>> use a JSON::XS thread safe alternative- there are several.
>>>
>>> Get Outlook for iOS
>>> --
>>> *From:* Joe Schaefer
>>> *Sent:* Monday, August 29, 2022 12:49:22 PM
>>> *To:* mod_perl list
>>> *Subject:* Re: sealed.pm v4.0.0 is out
>>>
>>> There is a mountain of awful advice floating around about ithreads,
>>> including pretty much everything going on in Raku around adopting the
>>> node.js model instead. It is safe to ignore all that now that SawyerX spit
>>> polished all of the perl5 internals.
>>>
>>> Get Outlook for iOS
>>> --
>>> *From:* Joe Schaefer
>>> *Sent:*
Re: sealed.pm v4.0.0 is out
Someday this patch might be interesting:
diff -u RegistryCooker.pm~ RegistryCooker.pm
--- RegistryCooker.pm~ 2022-08-30 11:10:19.790171019 -0400
+++ RegistryCooker.pm 2022-08-30 11:12:34.319572045 -0400
@@ -399,7 +399,8 @@
my $eval = join '',
'package ',
$self->{PACKAGE}, ";",
-"sub handler {",
+"use base 'sealed';",
+"sub handler :Sealed {",
"local \$0 = '$script_name';",
$nph,
$shebang,
On Mon, Aug 29, 2022 at 2:21 PM Joe Schaefer wrote:
> Forgive me for the pent up frustration of having our wonderful mod_perl
> project being completely ignored and abandoned by the Perl Steering
> Committee's frivolous lingustic interests over the years since the Parrot
> announcement.
> SaywerX gave us a reason to be hopeful again. Let's see what they do with
> it.
>
> On Mon, Aug 29, 2022 at 1:34 PM Joe Schaefer wrote:
>
>> If the Perl steering committee had any brains left it would have
>> capitalized on the perl 5.34 release and Co announced modperl2 ithread
>> compatibility now available with Perl7’s new release.
>>
>> Instead they are going to kick the tires on the defaults for strictures
>> and warnings until nobody cares any more.
>>
>> Get Outlook for iOS
>> --
>> *From:* Joe Schaefer
>> *Sent:* Monday, August 29, 2022 1:17:17 PM
>> *To:* mod_perl list
>> *Subject:* Re: sealed.pm v4.0.0 is out
>>
>> The only reason I’ve been vacillating about glibc/malloc thread safety is
>> because I couldn’t fathom the fact that people still believed modperl isn’t
>> compatible with mpm_event at this point in the Perl7 storyline. The old
>> segfaults of the past that happened in glibc malloc were because Perl was
>> corrupting the heap in some other part of the codebase, and there’s no
>> simple way to track it down without a tool like Valgrind, but we weren’t
>> successful with that effort either.
>>
>> Get Outlook for iOS
>> --
>> *From:* Joe Schaefer
>> *Sent:* Monday, August 29, 2022 1:08:00 PM
>> *To:* mod_perl list
>> *Subject:* Re: sealed.pm v4.0.0 is out
>>
>> Religiously avoid setting up per request ithread environment variables.
>> Just use PerlSetEnv in your Webserver config. Everything we did in modperl
>> to support CGI scripts is a train wreck.
>>
>> Get Outlook for iOS
>> --
>> *From:* Joe Schaefer
>> *Sent:* Monday, August 29, 2022 1:04:03 PM
>> *To:* mod_perl list
>> *Subject:* Re: sealed.pm v4.0.0 is out
>>
>> Look into reducing the scope of your interpreters down from the request
>> level to the handler level. If all you are doing is running registry
>> scripts, you will get even better scaling out of just a few ithreads per
>> worker process.
>>
>> Get Outlook for iOS
>> --
>> *From:* Joe Schaefer
>> *Sent:* Monday, August 29, 2022 12:57:14 PM
>> *To:* mod_perl list
>> *Subject:* Re: sealed.pm v4.0.0 is out
>>
>> The only impact to your work with modperl is that you will need to assess
>> the ithread-safety of your dependent XS-based modules. For example, use a
>> JSON::XS thread safe alternative- there are several.
>>
>> Get Outlook for iOS
>> --
>> *From:* Joe Schaefer
>> *Sent:* Monday, August 29, 2022 12:49:22 PM
>> *To:* mod_perl list
>> *Subject:* Re: sealed.pm v4.0.0 is out
>>
>> There is a mountain of awful advice floating around about ithreads,
>> including pretty much everything going on in Raku around adopting the
>> node.js model instead. It is safe to ignore all that now that SawyerX spit
>> polished all of the perl5 internals.
>>
>> Get Outlook for iOS
>> --
>> *From:* Joe Schaefer
>> *Sent:* Monday, August 29, 2022 12:40:43 PM
>> *To:* mod_perl list
>> *Subject:* Re: sealed.pm v4.0.0 is out
>>
>> Many of the performance hacks we’ve encouraged over the years, eg around
>> HTTPD’s lingering close effect, are obsoleted with ithreads. Unless you
>> send flush buckets down the output filter stack yourself, the “response
>> handler” phase exits long before the “connection handler” starts making non
>> blocking socket system calls. So you need an order of magnitude fewer
>> ithreads than you do prefork children in a multitier arch.
>>
>> Get Outlook for iOS
>> --
>> *From:* Joe Schaefer
>> *Sent:* Sunday, August 28, 2022 11:09:14 AM
>> *To:* mod_perl list
>> *Subject:* Re: sealed.pm v4.0.0 is out
>>
>> Benchmark ran on my 2021 Dell Precision Laptop w/ 8 cores + HT (so
>> 16vCPU) and Ubuntu 22.04 inside WSL2. Never topped 50% avg CPU, and almost
>> all of the CPU was in userland (not system calls).
>>
>> On Sat, Aug 27, 2022 at 11:42 AM wrote:
