gt;> around
>>>>>>>>>>>> with a user-generated one.
>>>>>>>>>>>> There's no good way to remove the target "method_named" op that
>>>>>>>>>>>> we're repla
t;>>>>>>>>>> be handled from perl itself. The problem is that the politics
>>>>>>>>>>> around the feature were never resolved, because nobody wants to
>>>>>>>>>>> change the
>>>>
gt;>>>>> around the feature were never resolved, because nobody wants to
>>>>>>>>>> change the
>>>>>>>>>> default "virtual method"
>>>>>>>>>> behavior of Perl's OO-runtime-lookup
gt;>>>>>>> just like we do for the :method attribute.
>>>>>>>>>
>>>>>>>>> On Tue, Aug 30, 2022 at 11:26 AM Joe Schaefer
>>>>>>>>> wrote:
>>>>>>>>>
>
gt;> Someday this patch might be interesting:
>>>>>>>>>
>>>>>>>>> diff -u RegistryCooker.pm~ RegistryCooker.pm
>>>>>>>>> --- RegistryCooker.pm~ 2022-08-30 11:10:19.790171019 -0400
>>>>>>>>> ++
7 +399,8 @@
>>>>>>>> my $eval = join '',
>>>>>>>> 'package ',
>>>>>>>> $self->{PACKAGE}, ";",
>>>>>>>> -"sub handler {
;>>>> Steering Committee's frivolous lingustic interests over the years
>>>>>>>> since the
>>>>>>>> Parrot announcement.
>>>>>>>> SaywerX gave us a reason to be hopeful again. Let&
gt;>>>
>>>>>> 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
; 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
>>>>>&
;> 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:
>&
gt;>>> 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:
>>>>
>>>>>
gt;>
>>> 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 Per
t;> 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 <https://aka.ms/o0ukef>
>>> -
t;
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> --
>> *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 b
hey are going to kick the tires on the defaults for strictures
> and warnings until nobody cares any more.
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> --
> *From:* Joe Schaefer
> *Sent:* Monday, August 29, 2022 1:17:17 PM
> *To:* mod
any more.
Get Outlook for iOS<https://aka.ms/o0ukef>
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 co
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
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 it
kef>
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
m: 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 th
kef>
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. Unle
ct: 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
mailto:j...@sunstarsys.com>>
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:
> See https://sunstarsys.com/essays/perl7-sealed-lexicals. F
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
So a <600MB total RSS footprint for the entire show, and I can stably
sustain 1000 concurrent ModPerl::Registry requests, in a few milliseconds
per request.
Good luck doing anything this efficiently with a multi-tiered dynamic
content delivery regime
24 matches
Mail list logo
