Re: Unorthodox Embedding/XS madness!

This may not be a popular suggestion, but would it be possible to abandon XS and try Inline::C instead? I haven't used either, but Ingy's talk about how he came up with Inline::C at the Montreal YAPC was most illuminating.

In addition, I see that CPAN also has Inline::CPR, something that lets you run Perl from within C.

And in terms of having to inject subs dynamically, is that necessary? Could you instead subsitute a more general piece of code that Does The Right Thing when called?

--t. alex
but my friends call me T.

Comment on Re: Unorthodox Embedding/XS madness!

Replies are listed 'Best First'.
Re: Re: Unorthodox Embedding/XS madness! by Ouroborous (Initiate) on Oct 10, 2002 at 06:46 UTC
I may have found the answer. My Perl distro (ActiveState, which is a 5.6.1 Win32 port), is compiled without either USE_THREADS or USE_ITHREADS. I'm not sure why that should matter (aren't these just for INTERNAL Perl threading?) but I've discovered that if I call eval_pv() from a __different O/S thread__ than the one I initialized the interpreter in, it traps. If I call from the same thread, it doesn't. I debugged it a little and found some calls to various TLS functions, so it appears that the simple expedient of storing my_perl in a global variable wasn't enough. Behind the scenes a pointer to it was getting stashed in thread-local storage, so that when I switched context over to my other thread, the pointer was null (different TLS instance) and we trapped as soon as we tried to use the interpreter pointer. VERY non-intuitive... As a C++ coder, I assume that if I dereference a global variable, it will have the same value over all functions in the module (assuming it isn't changed locally). However, this doesn't seem to match the actual behavior I'm seeing...	[reply]

Replies are listed 'Best First'.

Re: Re: Unorthodox Embedding/XS madness!
by Ouroborous (Initiate) on Oct 10, 2002 at 06:46 UTC

I may have found the answer. My Perl distro (ActiveState, which is a 5.6.1 Win32 port), is compiled without either USE_THREADS or USE_ITHREADS. I'm not sure why that should matter (aren't these just for INTERNAL Perl threading?) but I've discovered that if I call eval_pv() from a __different O/S thread__ than the one I initialized the interpreter in, it traps. If I call from the same thread, it doesn't. I debugged it a little and found some calls to various TLS functions, so it appears that the simple expedient of storing my_perl in a global variable wasn't enough. Behind the scenes a pointer to it was getting stashed in thread-local storage, so that when I switched context over to my other thread, the pointer was null (different TLS instance) and we trapped as soon as we tried to use the interpreter pointer. VERY non-intuitive... As a C++ coder, I assume that if I dereference a global variable, it will have the same value over all functions in the module (assuming it isn't changed locally). However, this doesn't seem to match the actual behavior I'm seeing...

[reply]