Re: sealed.pm v4.0.0 is out
Submitted a Pull Request for the Generate.xs patch:
https://github.com/rurban/b-generate/pull/2
Added more comments to sealed.pm to explain the rationale behind the #
replace $methop logic,
since it differs from what Doug did back in 2000.
On Tue, Aug 30, 2022 at 2:52 PM Joe Schaefer wrote:
> 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 fa
Re: sealed.pm v4.0.0 is out
The :sealed attribute is a statement about a class's @ISA: you are saying
you are using its compile-time setting.
And because we invoke $class->can to do the lookup, module authors who
override UNIVERSAL::can() with a customized
one can support AUTOLOADed methods themselves.
Under :sealed, you control which lexical object references you want to use
compile-time method lookups (via can()),
by declaring them with a class (type), or avoiding doing that in the
lexical's declaration. It only impacts your subroutine
definitions that declare :sealed and a typed lexicals, not any other
module's code elsewhere.
You absolutely *can* use sealed.pm outside mod_perl, but you need to be
wary about using typed lexicals on your method
argument stack, because end-users may pass properly derived objects to your
method, and will expect your module to use
the derived-class's overrides of any method calls in your codebase.
Basically the law of the land is that consumers of an API
expect all method calls to operate the way *virtual* method calls work in
Java/C++. However, what you do internally with API's
outside of your published API's argument stack is fair game for :sealed.
My advice that it's only practical to seal XS method calls remains.
On Wed, Aug 31, 2022 at 9:52 AM Joe Schaefer wrote:
> Submitted a Pull Request for the Generate.xs patch:
> https://github.com/rurban/b-generate/pull/2
> Added more comments to sealed.pm to explain the rationale behind the #
> replace $methop logic,
> since it differs from what Doug did back in 2000.
>
> On Tue, Aug 30, 2022 at 2:52 PM Joe Schaefer wrote:
>
>> 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 {",
>>
Re: sealed.pm v4.0.0 is out
In the end, the surgery we do (to method_named), is to replace the prior $op's next() pointer to point at the $gv op we copied from a known subroutine's op-tree (that uses a typical subroutine call instead of a method lookup). Since we relocated that next() pointer, we need to decrement the internal refcnt for the method_named op to avoid leaks/segfaults during garbage collection of the ithread. None of the many issues Doug faced back in 2000 to do this on a more generic level actually need to be done for this implementation. You just need to know that any code that tries to walk this tree (eg B::Deparse) post-tweaks may choke on the zombie method_named op lying around in one of the sibling() linked lists. That probably includes the ithread-cloniing mechanism itself, so only use :sealed post ithread construction, not prior to it. On Wed, Aug 31, 2022 at 10:27 AM Joe Schaefer wrote: > The :sealed attribute is a statement about a class's @ISA: you are saying > you are using its compile-time setting. > And because we invoke $class->can to do the lookup, module authors who > override UNIVERSAL::can() with a customized > one can support AUTOLOADed methods themselves. > > Under :sealed, you control which lexical object references you want to use > compile-time method lookups (via can()), > by declaring them with a class (type), or avoiding doing that in the > lexical's declaration. It only impacts your subroutine > definitions that declare :sealed and a typed lexicals, not any other > module's code elsewhere. > > You absolutely *can* use sealed.pm outside mod_perl, but you need to be > wary about using typed lexicals on your method > argument stack, because end-users may pass properly derived objects to > your method, and will expect your module to use > the derived-class's overrides of any method calls in your codebase. > Basically the law of the land is that consumers of an API > expect all method calls to operate the way *virtual* method calls work in > Java/C++. However, what you do internally with API's > outside of your published API's argument stack is fair game for :sealed. > My advice that it's only practical to seal XS method calls remains. > > On Wed, Aug 31, 2022 at 9:52 AM Joe Schaefer wrote: > >> Submitted a Pull Request for the Generate.xs patch: >> https://github.com/rurban/b-generate/pull/2 >> Added more comments to sealed.pm to explain the rationale behind the # >> replace $methop logic, >> since it differs from what Doug did back in 2000. >> >> On Tue, Aug 30, 2022 at 2:52 PM Joe Schaefer wrote: >> >>> 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 prob
Re: h2c benchmarks with same Ubuntu tune as before
To explain the new-new here, with HTTP/2 comes this whole new idea of multiplexed "HTTP channels" within a single TCP connection. In this benchmark, each of the 1000 concurrent tcp connections has 100 multiplexed requests to the same URL as on the command line. The reason mod_http2 need threads is to explode these multiplexed channels into independent requests within the same server process context. Otherwise it'd have to queue them (it could, but really not the point of multiplexing in the spec). In effect, you are seeing my laptop respond to 1 simultaneous requests for that URL. Most of this is serialized by the thread limits baked into mpm_event.conf and perl.conf, but it's still standing at the end of the exercise. On Mon, Aug 29, 2022 at 10:02 PM wrote: > h2load -n 10 -c 1000 -m 100 http://localhost/perl-script/enquiry.pl > > starting benchmark... > > spawning thread #0: 1000 total client(s). 10 total requests > > Application protocol: h2c > > progress: 10% done > > progress: 20% done > > progress: 30% done > > progress: 40% done > > progress: 50% done > > progress: 60% done > > progress: 70% done > > progress: 80% done > > progress: 90% done > > progress: 100% done > > > > finished in 11.60s, 8624.38 req/s, 11.13MB/s > > requests: 10 total, 10 started, 10 done, 10 succeeded, 0 > failed, 0 errored, 0 timeout > > status codes: 10 2xx, 0 3xx, 0 4xx, 0 5xx > > traffic: 129.04MB (135312547) total, 560.93KB (574391) headers (space > savings 95.51%), 126.74MB (13290) data min > max mean sd+/- sd > > time for request: 225.73ms 11.31s 5.76s 3.09s58.62% > > time for connect:15.40ms212.74ms 62.57ms 54.73ms87.50% > > time to 1st byte: 261.01ms 9.04s 3.00s 2.01s68.00% > > req/s : 8.70 68.06 15.649.7385.70% > > > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: h2c benchmarks with same Ubuntu tune as before
*100_000 simultaneous requests. On Wed, Aug 31, 2022 at 12:41 PM Joe Schaefer wrote: > To explain the new-new here, with HTTP/2 comes this whole new idea of > multiplexed "HTTP channels" within a single TCP connection. In this > benchmark, each of the 1000 concurrent tcp connections has 100 multiplexed > requests to the same URL as on the command line. > The reason mod_http2 need threads is to explode these multiplexed channels > into independent requests within the same server process context. > Otherwise it'd have to queue them (it could, but really not the point of > multiplexing in the spec). > In effect, you are seeing my laptop respond to 1 simultaneous requests > for that URL. Most of this is serialized by the thread limits baked into > mpm_event.conf and perl.conf, but it's still standing at the end of the > exercise. > > On Mon, Aug 29, 2022 at 10:02 PM wrote: > >> h2load -n 10 -c 1000 -m 100 http://localhost/perl-script/enquiry.pl >> >> starting benchmark... >> >> spawning thread #0: 1000 total client(s). 10 total requests >> >> Application protocol: h2c >> >> progress: 10% done >> >> progress: 20% done >> >> progress: 30% done >> >> progress: 40% done >> >> progress: 50% done >> >> progress: 60% done >> >> progress: 70% done >> >> progress: 80% done >> >> progress: 90% done >> >> progress: 100% done >> >> >> >> finished in 11.60s, 8624.38 req/s, 11.13MB/s >> >> requests: 10 total, 10 started, 10 done, 10 succeeded, 0 >> failed, 0 errored, 0 timeout >> >> status codes: 10 2xx, 0 3xx, 0 4xx, 0 5xx >> >> traffic: 129.04MB (135312547) total, 560.93KB (574391) headers (space >> savings 95.51%), 126.74MB (13290) data min >> max mean sd+/- sd >> >> time for request: 225.73ms 11.31s 5.76s 3.09s58.62% >> >> time for connect:15.40ms212.74ms 62.57ms 54.73ms87.50% >> >> time to 1st byte: 261.01ms 9.04s 3.00s 2.01s68.00% >> >> req/s : 8.70 68.06 15.649.7385.70% >> >> >> >> >> > > > -- > Joe Schaefer, Ph.D. > We only build what you need built. > > 954.253.3732 > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: sealed.pm v4.0.0 is out
For my part in this story, v4.0.0 is the end of the line. This release solves every business problem my own company had with prior releases, so I'm satisfied with where it lies. But it is not perfect by any stretch. To take it to the level where it needs to be someday, B::Generate's maintainers need to be reliable partners with the future maintainers of sealed.pm, to deal with whatever long-range support issues crop up as perlguts invariably undergoes changes that break the undocumented assumptions I've made in getting this into workable condition. What do you think about the idea of putting sealed.pm into the modperl project, vs. a stand-alone on CPAN? On Wed, Aug 31, 2022 at 10:53 AM Joe Schaefer wrote: > In the end, the surgery we do (to method_named), is to replace the prior > $op's next() pointer to point at the $gv op we copied from > a known subroutine's op-tree (that uses a typical subroutine call instead > of a method lookup). Since we relocated that next() pointer, > we need to decrement the internal refcnt for the method_named op to avoid > leaks/segfaults during garbage collection of the ithread. > > None of the many issues Doug faced back in 2000 to do this on a more > generic level actually need to be done for this implementation. > You just need to know that any code that tries to walk this tree (eg > B::Deparse) post-tweaks may choke on the zombie method_named > op lying around in one of the sibling() linked lists. That probably > includes the ithread-cloniing mechanism itself, so only use :sealed > post ithread construction, not prior to it. > > On Wed, Aug 31, 2022 at 10:27 AM Joe Schaefer wrote: > >> The :sealed attribute is a statement about a class's @ISA: you are saying >> you are using its compile-time setting. >> And because we invoke $class->can to do the lookup, module authors who >> override UNIVERSAL::can() with a customized >> one can support AUTOLOADed methods themselves. >> >> Under :sealed, you control which lexical object references you want to >> use compile-time method lookups (via can()), >> by declaring them with a class (type), or avoiding doing that in the >> lexical's declaration. It only impacts your subroutine >> definitions that declare :sealed and a typed lexicals, not any other >> module's code elsewhere. >> >> You absolutely *can* use sealed.pm outside mod_perl, but you need to be >> wary about using typed lexicals on your method >> argument stack, because end-users may pass properly derived objects to >> your method, and will expect your module to use >> the derived-class's overrides of any method calls in your codebase. >> Basically the law of the land is that consumers of an API >> expect all method calls to operate the way *virtual* method calls work in >> Java/C++. However, what you do internally with API's >> outside of your published API's argument stack is fair game for :sealed. >> My advice that it's only practical to seal XS method calls remains. >> >> On Wed, Aug 31, 2022 at 9:52 AM Joe Schaefer wrote: >> >>> Submitted a Pull Request for the Generate.xs patch: >>> https://github.com/rurban/b-generate/pull/2 >>> Added more comments to sealed.pm to explain the rationale behind the # >>> replace $methop logic, >>> since it differs from what Doug did back in 2000. >>> >>> On Tue, Aug 30, 2022 at 2:52 PM Joe Schaefer wrote: >>> 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). >>> No
Re: sealed.pm v4.0.0 is out
I went ahead and copied my company templates over to the github cms repo, so you can run enquiry.pl yourself (once you edit the @TEMPLATE_DIRS path to point at your checkout). You will see sealed.pm at work in the httpd error logs. On Wed, Aug 31, 2022 at 1:02 PM Joe Schaefer wrote: > For my part in this story, v4.0.0 is the end of the line. This release > solves every business problem my own company > had with prior releases, so I'm satisfied with where it lies. > > But it is not perfect by any stretch. To take it to the level where it > needs to be someday, B::Generate's maintainers need to be reliable > partners with the future maintainers of sealed.pm, to deal with whatever > long-range support issues crop up as perlguts invariably > undergoes changes that break the undocumented assumptions I've made in > getting this into workable condition. > > What do you think about the idea of putting sealed.pm into the modperl > project, vs. a stand-alone on CPAN? > > On Wed, Aug 31, 2022 at 10:53 AM Joe Schaefer wrote: > >> In the end, the surgery we do (to method_named), is to replace the prior >> $op's next() pointer to point at the $gv op we copied from >> a known subroutine's op-tree (that uses a typical subroutine call instead >> of a method lookup). Since we relocated that next() pointer, >> we need to decrement the internal refcnt for the method_named op to avoid >> leaks/segfaults during garbage collection of the ithread. >> >> None of the many issues Doug faced back in 2000 to do this on a more >> generic level actually need to be done for this implementation. >> You just need to know that any code that tries to walk this tree (eg >> B::Deparse) post-tweaks may choke on the zombie method_named >> op lying around in one of the sibling() linked lists. That probably >> includes the ithread-cloniing mechanism itself, so only use :sealed >> post ithread construction, not prior to it. >> >> On Wed, Aug 31, 2022 at 10:27 AM Joe Schaefer wrote: >> >>> The :sealed attribute is a statement about a class's @ISA: you are >>> saying you are using its compile-time setting. >>> And because we invoke $class->can to do the lookup, module authors who >>> override UNIVERSAL::can() with a customized >>> one can support AUTOLOADed methods themselves. >>> >>> Under :sealed, you control which lexical object references you want to >>> use compile-time method lookups (via can()), >>> by declaring them with a class (type), or avoiding doing that in the >>> lexical's declaration. It only impacts your subroutine >>> definitions that declare :sealed and a typed lexicals, not any other >>> module's code elsewhere. >>> >>> You absolutely *can* use sealed.pm outside mod_perl, but you need to be >>> wary about using typed lexicals on your method >>> argument stack, because end-users may pass properly derived objects to >>> your method, and will expect your module to use >>> the derived-class's overrides of any method calls in your codebase. >>> Basically the law of the land is that consumers of an API >>> expect all method calls to operate the way *virtual* method calls work >>> in Java/C++. However, what you do internally with API's >>> outside of your published API's argument stack is fair game for >>> :sealed. My advice that it's only practical to seal XS method calls >>> remains. >>> >>> On Wed, Aug 31, 2022 at 9:52 AM Joe Schaefer wrote: >>> Submitted a Pull Request for the Generate.xs patch: https://github.com/rurban/b-generate/pull/2 Added more comments to sealed.pm to explain the rationale behind the # replace $methop logic, since it differs from what Doug did back in 2000. On Tue, Aug 30, 2022 at 2:52 PM Joe Schaefer wrote: > 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 s
Re: sealed.pm v4.0.0 is out
To throw mod_apreq2 into the benchmarking mix, add items to the query
string you are hitting (on enquiry.pl).
In particular, lang=.{en,es,de,fr} will generate UTF-8 European-language
localized output.
On Wed, Aug 31, 2022 at 7:13 PM Joe Schaefer wrote:
> I went ahead and copied my company templates over to the github cms repo,
> so you can run enquiry.pl yourself
> (once you edit the @TEMPLATE_DIRS path to point at your checkout). You
> will see sealed.pm at work in the
> httpd error logs.
>
> On Wed, Aug 31, 2022 at 1:02 PM Joe Schaefer wrote:
>
>> For my part in this story, v4.0.0 is the end of the line. This release
>> solves every business problem my own company
>> had with prior releases, so I'm satisfied with where it lies.
>>
>> But it is not perfect by any stretch. To take it to the level where it
>> needs to be someday, B::Generate's maintainers need to be reliable
>> partners with the future maintainers of sealed.pm, to deal with whatever
>> long-range support issues crop up as perlguts invariably
>> undergoes changes that break the undocumented assumptions I've made in
>> getting this into workable condition.
>>
>> What do you think about the idea of putting sealed.pm into the modperl
>> project, vs. a stand-alone on CPAN?
>>
>> On Wed, Aug 31, 2022 at 10:53 AM Joe Schaefer wrote:
>>
>>> In the end, the surgery we do (to method_named), is to replace the prior
>>> $op's next() pointer to point at the $gv op we copied from
>>> a known subroutine's op-tree (that uses a typical subroutine call
>>> instead of a method lookup). Since we relocated that next() pointer,
>>> we need to decrement the internal refcnt for the method_named op to
>>> avoid leaks/segfaults during garbage collection of the ithread.
>>>
>>> None of the many issues Doug faced back in 2000 to do this on a more
>>> generic level actually need to be done for this implementation.
>>> You just need to know that any code that tries to walk this tree (eg
>>> B::Deparse) post-tweaks may choke on the zombie method_named
>>> op lying around in one of the sibling() linked lists. That probably
>>> includes the ithread-cloniing mechanism itself, so only use :sealed
>>> post ithread construction, not prior to it.
>>>
>>> On Wed, Aug 31, 2022 at 10:27 AM Joe Schaefer
>>> wrote:
>>>
The :sealed attribute is a statement about a class's @ISA: you are
saying you are using its compile-time setting.
And because we invoke $class->can to do the lookup, module authors who
override UNIVERSAL::can() with a customized
one can support AUTOLOADed methods themselves.
Under :sealed, you control which lexical object references you want to
use compile-time method lookups (via can()),
by declaring them with a class (type), or avoiding doing that in the
lexical's declaration. It only impacts your subroutine
definitions that declare :sealed and a typed lexicals, not any other
module's code elsewhere.
You absolutely *can* use sealed.pm outside mod_perl, but you need to
be wary about using typed lexicals on your method
argument stack, because end-users may pass properly derived objects to
your method, and will expect your module to use
the derived-class's overrides of any method calls in your codebase.
Basically the law of the land is that consumers of an API
expect all method calls to operate the way *virtual* method calls work
in Java/C++. However, what you do internally with API's
outside of your published API's argument stack is fair game for
:sealed. My advice that it's only practical to seal XS method calls
remains.
On Wed, Aug 31, 2022 at 9:52 AM Joe Schaefer
wrote:
> Submitted a Pull Request for the Generate.xs patch:
> https://github.com/rurban/b-generate/pull/2
> Added more comments to sealed.pm to explain the rationale behind the
> # replace $methop logic,
> since it differs from what Doug did back in 2000.
>
> On Tue, Aug 30, 2022 at 2:52 PM Joe Schaefer
> wrote:
>
>> 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, ev
Re: sealed.pm v4.0.0 is out
4.0.1 is going to trap everything bizarre that occurs within the tweak()
subroutine, and gracefully bail out.
The only thing this needs your help with is to avoid putting heavy ithread
pressure on mod_perl during interpreter
destruction. One simple approach is to make sure your modperl interpreter
settings never destroy ithreads-
leave that for httpd during graceful restart.
On Wed, Aug 31, 2022 at 7:41 PM Joe Schaefer wrote:
> To throw mod_apreq2 into the benchmarking mix, add items to the query
> string you are hitting (on enquiry.pl).
> In particular, lang=.{en,es,de,fr} will generate UTF-8 European-language
> localized output.
>
> On Wed, Aug 31, 2022 at 7:13 PM Joe Schaefer wrote:
>
>> I went ahead and copied my company templates over to the github cms repo,
>> so you can run enquiry.pl yourself
>> (once you edit the @TEMPLATE_DIRS path to point at your checkout). You
>> will see sealed.pm at work in the
>> httpd error logs.
>>
>> On Wed, Aug 31, 2022 at 1:02 PM Joe Schaefer wrote:
>>
>>> For my part in this story, v4.0.0 is the end of the line. This release
>>> solves every business problem my own company
>>> had with prior releases, so I'm satisfied with where it lies.
>>>
>>> But it is not perfect by any stretch. To take it to the level where it
>>> needs to be someday, B::Generate's maintainers need to be reliable
>>> partners with the future maintainers of sealed.pm, to deal with
>>> whatever long-range support issues crop up as perlguts invariably
>>> undergoes changes that break the undocumented assumptions I've made in
>>> getting this into workable condition.
>>>
>>> What do you think about the idea of putting sealed.pm into the modperl
>>> project, vs. a stand-alone on CPAN?
>>>
>>> On Wed, Aug 31, 2022 at 10:53 AM Joe Schaefer
>>> wrote:
>>>
In the end, the surgery we do (to method_named), is to replace the
prior $op's next() pointer to point at the $gv op we copied from
a known subroutine's op-tree (that uses a typical subroutine call
instead of a method lookup). Since we relocated that next() pointer,
we need to decrement the internal refcnt for the method_named op to
avoid leaks/segfaults during garbage collection of the ithread.
None of the many issues Doug faced back in 2000 to do this on a more
generic level actually need to be done for this implementation.
You just need to know that any code that tries to walk this tree (eg
B::Deparse) post-tweaks may choke on the zombie method_named
op lying around in one of the sibling() linked lists. That probably
includes the ithread-cloniing mechanism itself, so only use :sealed
post ithread construction, not prior to it.
On Wed, Aug 31, 2022 at 10:27 AM Joe Schaefer
wrote:
> The :sealed attribute is a statement about a class's @ISA: you are
> saying you are using its compile-time setting.
> And because we invoke $class->can to do the lookup, module authors who
> override UNIVERSAL::can() with a customized
> one can support AUTOLOADed methods themselves.
>
> Under :sealed, you control which lexical object references you want to
> use compile-time method lookups (via can()),
> by declaring them with a class (type), or avoiding doing that in the
> lexical's declaration. It only impacts your subroutine
> definitions that declare :sealed and a typed lexicals, not any other
> module's code elsewhere.
>
> You absolutely *can* use sealed.pm outside mod_perl, but you need to
> be wary about using typed lexicals on your method
> argument stack, because end-users may pass properly derived objects to
> your method, and will expect your module to use
> the derived-class's overrides of any method calls in your codebase.
> Basically the law of the land is that consumers of an API
> expect all method calls to operate the way *virtual* method calls work
> in Java/C++. However, what you do internally with API's
> outside of your published API's argument stack is fair game for
> :sealed. My advice that it's only practical to seal XS method calls
> remains.
>
> On Wed, Aug 31, 2022 at 9:52 AM Joe Schaefer
> wrote:
>
>> Submitted a Pull Request for the Generate.xs patch:
>> https://github.com/rurban/b-generate/pull/2
>> Added more comments to sealed.pm to explain the rationale behind the
>> # replace $methop logic,
>> since it differs from what Doug did back in 2000.
>>
>> On Tue, Aug 30, 2022 at 2:52 PM Joe Schaefer
>> wrote:
>>
>>> 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 f
Re: sealed.pm v4.0.0 is out
What I'm saying is that this isn't foolproof, but really neither is doing
mod_perl + ithreads without sealed.pm. A bad tune will blow up under
pressure,
so be careful out there in the brave new world of single-tiered
webstacks using mod_perl and mpm_event plus mod_http2.
On Wed, Aug 31, 2022 at 8:11 PM Joe Schaefer wrote:
> 4.0.1 is going to trap everything bizarre that occurs within the tweak()
> subroutine, and gracefully bail out.
> The only thing this needs your help with is to avoid putting heavy ithread
> pressure on mod_perl during interpreter
> destruction. One simple approach is to make sure your modperl interpreter
> settings never destroy ithreads-
> leave that for httpd during graceful restart.
>
>
> On Wed, Aug 31, 2022 at 7:41 PM Joe Schaefer wrote:
>
>> To throw mod_apreq2 into the benchmarking mix, add items to the query
>> string you are hitting (on enquiry.pl).
>> In particular, lang=.{en,es,de,fr} will generate UTF-8 European-language
>> localized output.
>>
>> On Wed, Aug 31, 2022 at 7:13 PM Joe Schaefer wrote:
>>
>>> I went ahead and copied my company templates over to the github cms
>>> repo, so you can run enquiry.pl yourself
>>> (once you edit the @TEMPLATE_DIRS path to point at your checkout). You
>>> will see sealed.pm at work in the
>>> httpd error logs.
>>>
>>> On Wed, Aug 31, 2022 at 1:02 PM Joe Schaefer wrote:
>>>
For my part in this story, v4.0.0 is the end of the line. This release
solves every business problem my own company
had with prior releases, so I'm satisfied with where it lies.
But it is not perfect by any stretch. To take it to the level where it
needs to be someday, B::Generate's maintainers need to be reliable
partners with the future maintainers of sealed.pm, to deal with
whatever long-range support issues crop up as perlguts invariably
undergoes changes that break the undocumented assumptions I've made in
getting this into workable condition.
What do you think about the idea of putting sealed.pm into the modperl
project, vs. a stand-alone on CPAN?
On Wed, Aug 31, 2022 at 10:53 AM Joe Schaefer
wrote:
> In the end, the surgery we do (to method_named), is to replace the
> prior $op's next() pointer to point at the $gv op we copied from
> a known subroutine's op-tree (that uses a typical subroutine call
> instead of a method lookup). Since we relocated that next() pointer,
> we need to decrement the internal refcnt for the method_named op to
> avoid leaks/segfaults during garbage collection of the ithread.
>
> None of the many issues Doug faced back in 2000 to do this on a more
> generic level actually need to be done for this implementation.
> You just need to know that any code that tries to walk this tree (eg
> B::Deparse) post-tweaks may choke on the zombie method_named
> op lying around in one of the sibling() linked lists. That probably
> includes the ithread-cloniing mechanism itself, so only use :sealed
> post ithread construction, not prior to it.
>
> On Wed, Aug 31, 2022 at 10:27 AM Joe Schaefer
> wrote:
>
>> The :sealed attribute is a statement about a class's @ISA: you are
>> saying you are using its compile-time setting.
>> And because we invoke $class->can to do the lookup, module authors
>> who override UNIVERSAL::can() with a customized
>> one can support AUTOLOADed methods themselves.
>>
>> Under :sealed, you control which lexical object references you want
>> to use compile-time method lookups (via can()),
>> by declaring them with a class (type), or avoiding doing that in the
>> lexical's declaration. It only impacts your subroutine
>> definitions that declare :sealed and a typed lexicals, not any other
>> module's code elsewhere.
>>
>> You absolutely *can* use sealed.pm outside mod_perl, but you need to
>> be wary about using typed lexicals on your method
>> argument stack, because end-users may pass properly derived objects
>> to your method, and will expect your module to use
>> the derived-class's overrides of any method calls in your codebase.
>> Basically the law of the land is that consumers of an API
>> expect all method calls to operate the way *virtual* method calls
>> work in Java/C++. However, what you do internally with API's
>> outside of your published API's argument stack is fair game for
>> :sealed. My advice that it's only practical to seal XS method calls
>> remains.
>>
>> On Wed, Aug 31, 2022 at 9:52 AM Joe Schaefer
>> wrote:
>>
>>> Submitted a Pull Request for the Generate.xs patch:
>>> https://github.com/rurban/b-generate/pull/2
>>> Added more comments to sealed.pm to explain the rationale behind
>>> the # replace $methop logic,
>>> since it differs from what Doug did back in 2000.
>>>
>>> On Tue, Aug 30, 2022 at 2:
