I found this function in perlguts, section "Examining internal data structures with the dump functions".

Well yeah, but that doesn't define the arguments. Not even just how many.

And it use both Perl_sv_dump() and sv_dump() in the same para implying they might be the same thing. But that post I linked suggests otherwise.

My attempts to use either here just crash.

I've been trying to wrap my brain around why your making a copy of the SV rather than just storing the SV* would make a difference, and the only thing that makes any sense is that this "mortality" thing. The SV* you receive points to a temporary SV that has been GC'd or reused by the time you try to use it.

Maybe if you incremented its refcount (the SV pointed at by the SV* you receive), then Perl would know there was another reference kicking around somewhere and not recycle it?

I thought I'd try that and it worked. This (minus the unchanged bits from above) allows me to use coderefs:

void setCallback( SV *cb1, SV* cb2, SV *cb3, SV *cb4 ) {
    int i;
    saved = Perl_get_context();
    callbacks[0] = cb1; SvREFCNT_inc( cb1 );
    callbacks[1] = cb2; SvREFCNT_inc( cb2 );
    callbacks[2] = cb3; SvREFCNT_inc( cb2 );
    callbacks[3] = cb4; SvREFCNT_inc( cb2 );
    for( i=1; i < 4; ++i ) InitializeSRWLock( &locks[ i ] );
    _beginthread( &thread1, 0, NULL );
    _beginthread( &thread2, 0, NULL );
    return;
}

END_C
$|++;

{
    package fred;
    my @c = (0) x 4;

    sub callback1 { ++$c[0]; print "PCB1: $_[0] ($c[0])"; return; }
    sub callback2 { ++$c[1]; print "PCB2: $_[0] ($c[1])"; return; }
    sub callback3 { ++$c[2]; print "PCB3: $_[0] ($c[2])"; return; }
    sub callback4 { ++$c[3]; print "PCB4: $_[0] ($c[3])"; return; }
}

setCallback( \&fred::callback1, \&fred::callback2, \&fred::callback3, 
+\&fred::callback4 );

sleep 100;
[download]

the only thing that makes any sense is that this "mortality" thing. The SV* you receive points to a temporary SV that has been GC'd or reused by the time you try to use it.

This was precisely my theory as well. I guess "out-of-scope" etc., werent the right phrases to describe in a perl context (I'm a "C" guy, learning Perl as needed).

Maybe if you incremented its refcount

I had just stumbled across this SvREFCNT_inc yesterday and was thinking of trying it. I'm glad to hear it worked for you.

Do you think I should still be worried about going ahead with this as the right solution? So far my testing hasnt shown any negative/unexpected results.

Do you think I should still be worried about going ahead with this as the right solution? So far my testing hasnt shown any negative/unexpected results.

Honestly, I am uncomfortable with expressing an opinion on that.

I am unaware of anyone else doing anything like this--sharing an interpreter context between multiple concurrent C-threads--so you are on bleeding edge without a backup or safety net.

You're running code I've never seen, on a platform I don't use. To run even theoretically correctly requires the use of mutexes. I've use platform dependant mutexes, you'll have to use something else. The only mechanism I'm aware of on your platform is pthreads cond_vars. At best I find these confusing to use; at worst down right flaky. They seem to be (akin to) "level triggered" rather than "edge triggered" interrupts, with all the ramifications that implies. You will have to code those and I cannot help you. Even if you posted your implementation, I couldn't judge it one way or another.

Whilst my implementation runs properly on my platform for as long as I care to leave it running, when it terminates it produces errors:

PCB4: 981451617 (9514 9775 9473 9835)
PCB2: 981451617 (9514 9776 9473 9835)
PCB4: 981451617 (9514 9775 9473 9835)
PCB2: 981451617 (9514 9776 9473 9835)
Modification of a read-only value attempted at C:\test\867652.pl line 
+64.
CCB[3]: 981451617
PCB4: 981451617 (9514 9776 9473 9836)
CCB[2]: 981451617
PCB3: 981451617 (9514 9776 9474 9836)
CCB[0]: 981451617
CCB[3]: 981451617
PCB1: 981451617 (9515 9776 9474 9836)
PCB4: 981451617 (9515 9776 9474 9837)
PCB1: 981451617 (9515 9776 9474 9836)
PCB4: 981451617 (9515 9776 9474 9837)
Modification of a read-only value attempted at C:\test\867652.pl line 
+61.
[download]

This is almost certainly because I have not coded a mechanism to terminate the C-threads, hence they attempt to call back when the perl thread is undergoing global destruction, and errors occur. But "Modification of a read-only value attempted ..." is a weird error to receive? Is that indicative of a coding error within the XS? Would it behave differently on your system (as with Perl_sv_dump)? I'm simply not qualified to answer that.

Also, you've never really explained why you need to use coderefs rather than qualified subnames? They have geven me less trouble on my system. They don't require me to mess around with mortality--which has to be a good thing :)

I haven't been able to exercise, much less test, your real code on your real platform, so any opinion I expressed would be a wild-assed guess, and frankly irresponsible. I'm not enamoured with that idea.

Finally, I'm not party to the criticality of your systems or data; or whether you are subsequently going to start selling your code as part of a package to run air traffic control systems, heart-beat monitors or similar. I cannot make that call for you. I do know that I would want to soak test this in a testbed environment for a good long while before declaring it production ready.

And if the system and data involved are in any way critical; multiple, distinct, realistic testbeds for considerably longer!

The the last partial code I posted contained several errors, so here is the full thing with the corrections:

#! perl -slw
use strict;
use Inline C => Config => BUILD_NOISY => 1;
use Inline C => <<'END_C',  NAME => '_867652', CLEAN_AFTER_BUILD => 0;
#include <windows.h>

PerlInterpreter *saved;
SV *callbacks[ 4 ];
SRWLOCK locks[ 4 ];

VOID CALLBACK cbProc( int cbn, DWORD time ) {
    printf( "CCB[%d]: %u\n", cbn, time );

    PERL_SET_CONTEXT( saved );
    {
        dSP;
        ENTER;
        SAVETMPS;
        PUSHMARK( SP );
        XPUSHs( sv_2mortal( newSVuv( (UV)time ) ) );
        PUTBACK;
        call_sv( callbacks[ cbn ], G_DISCARD );

        FREETMPS;
        LEAVE;
    }
    return;
}

void __cdecl thread( VOID *arg ) {
    while( Sleep( rand() & 7 ), 1 ) {
        int choice = rand() & 3;
        AcquireSRWLockExclusive( &locks[ choice ] );
        cbProc( choice, GetTickCount() );
        ReleaseSRWLockExclusive( &locks[ choice ] );
     }
}

void setCallback( SV *cb1, SV* cb2, SV *cb3, SV *cb4 ) {
    int i;
    saved = Perl_get_context();
    callbacks[0] = cb1; SvREFCNT_inc( cb1 );
    callbacks[1] = cb2; SvREFCNT_inc( cb2 );
    callbacks[2] = cb3; SvREFCNT_inc( cb3 );
    callbacks[3] = cb4; SvREFCNT_inc( cb4 );
    for( i=1; i < 4; ++i ) InitializeSRWLock( &locks[ i ] );
    _beginthread( &thread, 0, (void*)0 );
    _beginthread( &thread, 0, (void*)1 );
    _beginthread( &thread, 0, (void*)2 );
    _beginthread( &thread, 0, (void*)3 );
    return;
}

END_C
$|++;

{
    package fred;
    my @c = (0) x 4;

    sub callback1 { ++$c[0]; print "PCB1: $_[0] (@c)"; return; }
    sub callback2 { ++$c[1]; print "PCB2: $_[0] (@c)"; return; }
    sub callback3 { ++$c[2]; print "PCB3: $_[0] (@c)"; return; }
    sub callback4 { ++$c[3]; print "PCB4: $_[0] (@c)"; return; }
}

setCallback( 
    \&fred::callback1, 
    \&fred::callback2, 
    \&fred::callback3, 
    \&fred::callback4, 
);

sleep 100;
[download]

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy