Front page | perl.perl5.porters |
Postings from August 2017
On 08/09/2017 06:58 PM, Father Chrysostomos wrote: > Karl Williamson wrote: >> I have now checked about POSIX.xs, and it does not currently use the _r >> versions, but >> >> #define PERL_EXT >> >> at the top of the file causes it to. Is there a reason not to do this? > > No. PERL_EXT is specifically for core XS modules such as this that > need slightly-more-internal-than-CPAN treatment. > This is some text from perl_xs "Starting from Perl 5.8, in C/C++ level Perl knows how to wrap system/library interfaces that have thread-aware versions (e.g. getpwent_r()) into frontend macros (e.g. getpwent()) that correctly handle the multithreaded interaction with the Perl interpreter. This will happen transparently, the only thing you need to do is to instantiate a Perl interpreter. "This wrapping happens always when compiling Perl core source (PERL_CORE is defined) or the Perl core extensions (PERL_EXT is defined). When compiling XS code outside of Perl core the wrapping does not take place. Note, however, that intermixing the _r-forms (as Perl compiled for multithreaded operation will do) and the _r-less forms is neither well-defined (inconsistent results, data corruption, or even crashes become more likely), nor is it very portable." ----------------- This seems to be inviting authors to surreptitiously use PERL_EXT. What should we say?Thread Previous