Mailing List Archive

On Tue, Sep 12, 2023 at 07:10:45PM +0200, Lukas Mai wrote:
> I built perl 5.39.2 with PERL_RC_STACK. One of my modules,
> Function::Parameters, started failing:

Given that the PERL_RC_STACK work isn't even complete in the perl core
yet, I think you're jumping the gun a bit!

A lot of CPAN modules, including XS ones, work out of the box - some,
depending on circumstances, will require some work.

> http://www.cpantesters.org/cpan/report/55055e26-4050-11ee-8bd0-2f0c0197f5f7
> | perl5.39.2: Parameters.xs:1367: register_info: Assertion
> `!rpp_stack_is_rc()' failed.
>
> Is this the expected behavior?
>
> I got things to work again by manually patching all the PUSHMARK/EXTEND/PUSH
> sites with lots of #ifdef PERL_RC_STACK gates: https://github.com/mauke/Function-Parameters/commit/8df472a56657a410d4cd69da2579c527c155085a
>
> Is there a better way to do this? Should perlcall.pod be amended? Or am I
> doing it wrong?

In general, things get wrapped so that 'legacy' code can continue using
dSP and PUSHs etc. It's possible to rewrite such things using the new rpp_
API, which are designed to work in both PERL_RC_STACK and vanilla
environments. But the new rpp_ functions aren't in PPPort yet, so you
can't rewrite your code using them. Including them conditionally with
millions of #ifdefs is definitely not the approach to take.

In rare cases, code may be called from both refcounted stack environments
and non-refcounted environments. An example of this is perl's call_sv()
and similar, which can be called from anywhere, and so have to be
ambidextrous. Thus the body of call_sv() has a few #ifdefs.

I don't know about Function::Parameters and in particular how the
functions you've been modifying get invoked. But if there is a transition
from a refcounted stack to non-refcounted stack somewhere which isn't via
a normal XS call from pp_entersub, then it probably needs wrapping so
that it's given a temporarily non-refcounted stack to run on and so can
run unmodified.

But really, you'd be best off waiting until it's complete in core, the
rpp_() API has stabilised, and PPPort has been updated.


--
Diplomacy is telling someone to go to hell in such a way that they'll
look forward to the trip

On Wed, Sep 13, 2023 at 9:22?AM Dave Mitchell <davem@iabyn.com> wrote:

> [snip]
>
> Given that the PERL_RC_STACK work isn't even complete in the perl core
> yet, I think you're jumping the gun a bit!
>

Another gun jumper here. Feel free to totally ignore this post.
I'll just mention something that I've noticed with -DPERL_RC_STACK on
Windows.
I have (eg) an XSub in Math::GMPz called get_refcnt() which simply wraps
SvREFCNT().
I'm accustomed to seeing:

D:\>perl -MMath::GMPz -le "$z = 123; print Math::GMPz::get_refcnt($z);"
1

But with today's blead (commit 4e1743c0), I've built perl with
-DPERL_RC_STACK for the first time, and I'm getting:

D:\>perl -MMath::GMPz -le "$z = 123; print Math::GMPz::get_refcnt($z);"
2

I assume that this is under control and will be taken care of in due course.
But do let me know if this warrants further investigation, or if you want
additional information.

Cheers,
Rob

On Wed, Sep 13, 2023 at 11:25:12PM +1000, sisyphus wrote:
> Another gun jumper here. Feel free to totally ignore this post.
> I'll just mention something that I've noticed with -DPERL_RC_STACK on
> Windows.
> I have (eg) an XSub in Math::GMPz called get_refcnt() which simply wraps
> SvREFCNT().
> I'm accustomed to seeing:
>
> D:\>perl -MMath::GMPz -le "$z = 123; print Math::GMPz::get_refcnt($z);"
> 1
>
> But with today's blead (commit 4e1743c0), I've built perl with
> -DPERL_RC_STACK for the first time, and I'm getting:
>
> D:\>perl -MMath::GMPz -le "$z = 123; print Math::GMPz::get_refcnt($z);"
> 2
>
> I assume that this is under control and will be taken care of in due course.
> But do let me know if this warrants further investigation, or if you want
> additional information.

In general on PERL_RC_STACK builds, 'live' SVs (i.e. those currently on
the stack) will have a refcount 1 higher than they would on
non-PERL_RC_STACK builds.

--
Nothing ventured, nothing lost.

On 13.09.23 01:22, Dave Mitchell wrote:
[-snip-]
>
> I don't know about Function::Parameters and in particular how the
> functions you've been modifying get invoked. But if there is a transition
> from a refcounted stack to non-refcounted stack somewhere which isn't via
> a normal XS call from pp_entersub, then it probably needs wrapping so
> that it's given a temporarily non-refcounted stack to run on and so can
> run unmodified.

I don't know about stack transitions, but the XS code gets called from
the keyword plugin interface (from the parser), and it then calls back
into Perl at compile time.

> But really, you'd be best off waiting until it's complete in core, the
> rpp_() API has stabilised, and PPPort has been updated.

OK, thank you for your reply. I'll wait until things are a bit more
stable. Looks like I'll have to learn how Devel::PPPort works. :-)

On Wed, Sep 13, 2023 at 06:11:46PM +0200, Lukas Mai wrote:
> I don't know about stack transitions, but the XS code gets called from the
> keyword plugin interface (from the parser), and it then calls back into Perl
> at compile time.

Normally, XS code gets calls from pp_entersub, which is in a runops loop,
which is either at the top-level or has been invoked from something like
call_sv(). In those circumstances the XS code would be automatically
'wrapped' and old-style XS code would run just fine.

Your XS code getting called from the keyword plugin interface is an
unusual route and thus is somehow not getting wrapped, and most likely
implies that I need to look into it and ensure that that route gets
handled correctly by the perl core too.

I'll add it to my list of things to look into.

--
Decaffeinated coffee is like dehydrated water