On Thu, Feb 5, 2015 at 9:15 PM, Олег Пронин wrote:

Currently i'm having a lot of troubles with developing XS frameworks
while keeping support for threaded perls

1) annoying pTHX/aTHX
2) annoying class members 'my_perl' needed for destructors (or dTHX
instead) when PERL_NO_GET_CONTEXT (because C++ desctructors has no
args, you cant pass aTHX, so you either save my_perl as an object
member in constructor, or use less efficient dTHX in desctructor).
The same applies for callbacks which are called from C libs
(libevent/libuv) and works with perl variables.
Yes, this is certainly annoying, but I'm not really seeing a clean solution
to this issue. The macro-madness that mostly hides these complications in C
just doesn't port over well to C++.

3) C++ XS frameworks not working after threads->create, because you
either get core dump on double C++ object delete, or (if CLONE_SKIP)
get a ref to undef which is not better anyway.

I didn't find any callback/hook that perl calls on every blessed
object when perl_clone().
Is there any?
There is: svt_dup magic. File::Map and SysV::SharedMem are two modules of
mine that use it, there must be more of them. In those particular cases I'm
refcounting my resource, in other cases it may make sense to copy them

If not it seems impossible to properly implement XS objects with C
underlying data.
It is possible, but more complicated than it should be.

What is the status of threaded perl? does anybody use it? will it be
okay if XS cpan modules will no longer support it?
Everyone hates threads on perl, and XS authors more so. You wouldn't be the
first not to support it, but personally I do prefer to support it: there
are still uses for them.


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 5 | next ›
Discussion Overview
groupperl5-porters @
postedFeb 5, '15 at 8:15p
activeFeb 6, '15 at 8:34a



site design / logo © 2021 Grokbase