[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libclass-xsaccessor-perl: defining PERL_CORE for external XS modules and ABI stability



-=| Ansgar Burchardt, Mon, Aug 16, 2010 at 01:50:23PM +0900 |=-
> Hi,
> 
> the last upstream release of libclass-xsaccessor-perl (1.07) contains
> this change:
> 
> --8<---------------cut here---------------start------------->8---
> --- XSAccessor.xs       (revision 61639)
> +++ XSAccessor.xs       (working copy)
> @@ -1,7 +1,33 @@
>  #define PERL_NO_GET_CONTEXT
>  #include "EXTERN.h"
>  #include "perl.h"
> +
> +/*
> + * Quoting chocolateboy from his Method::Lexical module at 2009-02-08:
> + *
> + * for binary compatibility (see perlapi.h), XS modules perform a function call to
> + * access each and every interpreter variable. So, for instance, an innocuous-looking
> + * reference to PL_op becomes:
> + *
> + *     (*Perl_Iop_ptr(my_perl))
> + *
> + * This (obviously) impacts performance. Internally, PL_op is accessed as:
> + *
> + *     my_perl->Iop
> + *
> + * (in threaded/multiplicity builds (see intrpvar.h)), which is significantly faster.
> + *
> + * defining PERL_CORE gets us the fast version, at the expense of a future maintenance release
> + * possibly breaking things: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-04/msg00171.html
> + *
> + * Rather than globally defining PERL_CORE, which pokes its fingers into various headers, exposing
> + * internals we'd rather not see, just define it for XSUB.h, which includes
> + * perlapi.h, which imposes the speed limit.
> + */
> +
> +#define PERL_CORE
>  #include "XSUB.h"
> +#undef PERL_CORE
>  
>  #include "ppport.h"
>  
> --8<---------------cut here---------------end--------------->8---
> 
> I wonder whether it is safe to keep this in Debian as the XS modules depend
> on perlapi-*, or if this does not guarantee that (internal) offsets do
> not change and we should not define PERL_CORE for the Debian 
> package.

I think keeping this is safe. Perhaps even defining PERL_CORE globally 
would be safe. I guess the whle dance around perl internals is to 
allow the XS module to work with a perl binary with a different ABI -- 
something we solve differently in Debian.

Attachment: signature.asc
Description: Digital signature


Reply to: