develooper Front page | perl.perl5.porters | Postings from March 2023

Re: PERL_RC_STACK branch: first cut

Thread Previous | Thread Next
Zefram via perl5-porters
March 19, 2023 17:09
Re: PERL_RC_STACK branch: first cut
Message ID:
Dave Mitchell wrote:
>The branch containing the first stage of my "make the stack ref-counted"
>work is nearly ready for merging.

I'm pleased that the effort is being made to make the stack refcounted,
and from reading the new perlguts documentation it seems to me that this
is a good way to go about it.

>                     There is not yet an API to allow XS functions to be
>  written in an RC-aware way.

Please add such a thing before merging.  I have some modules that share
the stack-manipulating guts of operations between PP functions for custom
ops and XSUBs, and since I want the PP functions to be optimally fast
I'd be unhappy with making the PP functions wrap shared RC-unaware guts.
If XSUBs couldn't be marked as RC-aware then I'd have to develop a
wrapper to let XSUB code running with a non-RC stack call RC-using
PP code.  That need arises as soon as there's a Perl release on which
we expect PERL_RC_STACK builds to be supported but which doesn't support
RC-aware XSUBs.

The necessary API is only a CVf_ flag, which can be set by C code and
which pp_entersub consults to determine whether to do the split-stack
wrapping.  I can set this flag when I'm constructing XSUB CVs from
manually-written C code, which is generally how I construct them when
sharing guts with PP functions.  This doesn't require any support in

Eventually we'd want EU:PXS to have some syntax such as "RCPPCODE:"
to declare that a sub body is RC-aware.  This would make it generate
appropriate prologue and epilogue code in the XSUB body function,
and make it generate boot code that sets the CVf_ flag on the XSUB.
But this facility for ordinary XS code isn't as urgent as having the
underlying API facility.

>* Any XS code which includes a custom OP with its own PP function, or
>   contains a PP function intended to override a core PP function ,won't
>   work unmodified;.

As things stand, this kind of code would still compile fine, and just
screw up the refcounting at runtime.  It would be helpful if it were
possible to make some gratuitous API change that prevents the confusion
of old-style and new-style PP functions.  Ideally this would be a type
change that makes the function pointers incompatible at the C level.
The obvious way to do that would be to add a new parameter that is never
used, but I don't see how to avoid that imposing overhead in setting a
register value for that parameter.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About