Front page | perl.perl5.porters |
Postings from March 2023
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 ExtUtils::ParseXS. 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. -zeframThread Previous | Thread Next