On Sun, Nov 02, 2008 at 12:26:54AM +0200, Shmuel Fomberg wrote:
> Dave Mitchell wrote:
>>> A question about threads from the XS-embedding-module perspective:
>>> What is the difference between MY_CXT and PL_modglobal?
>>
>> PL_modglobal is a general perl-interpreter hash.
>
> So, if a interpreter creates new threads, every thread get its own copy
> of PL_modglobal?
Yes.
(I'm assuming you're creating threads from within Perl using threads.pm
rather than from C in the STAF program).
When the new thread is created, every element of PL_modglobal will be
copied (cloned) into the new interpreter.
>
>>> I have implemented C running Perl module that embed a C XS function,
>>> and want to pass a pointer to that function from the C code that
>>> runs Perl.
>>> The Perl side span multiple threads, and each call that C function.
>>
>> The usual way of doing this is to store the pointer in an SV using using
>> the PTR2UV and INT2PTR macros. This may remove your need to use MY_CXT.
>
> To hide the pointer inside a global (our) variable? And let the Perl
> name space be my storage. nice.
It doesn't even need to be an our variable. If could just be a temporary
argument to a function.
For example, if your C program wanted to call a Perl function which then
calls (via XS) a C function, and your C program wants to pass a pointer to
that C function, then could do something like:
XPUSHs(sv_2mortal(newSVuv(PTR2UV(my_ptr)));
...;
call_pv("my_perl_function",...);
And within perl you have:
sub my_perl_function {
my $ptr = shift;
my_xs_function($ptr);
}
And within your XS code:
void
my_xs_function(sv)
SV* sv
CODE:
void* my_ptr = INT2PTR(sv);
--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.
