BrowserUk has asked for the wisdom of the Perl Monks concerning the following question:

Can someone explain to me why autoload is getting involved here? (And how to fix it?).

#! perl -slw use strict; use Inline 'NoClean', 'FORCE', 'INFO' ; use Inline Config => WARNINGS => 4; use Inline 'C' => 'DATA', NAME =>'test'; sub calledBack{ print "calledBack with: @_"; } setCallback( \&calledBack ); callback(); __DATA__ __C__ SV* g_callback = 0; int setCallback ( SV*code ) { g_callback = code; return 0; } int callback () { call_sv( g_callback, G_VOID ); return 0; }
P:\test>test <-----------------------Information Section--------------------------- +--------> Information about the processing of your Inline C code: Your source code needs to be compiled. I'll use this build directory: P:\test\_Inline\build\test and I'll install the executable as: P:\test\_Inline\lib\auto\test\test.dll The following Inline C function(s) have been successfully bound to Per +l: int callback() int setCallback(SV * code) <-----------------------End of Information Section-------------------- +--------> Use of uninitialized value in null operation at P:\test\test.pl line 1 +2. Use of inherited AUTOLOAD for non-method main::() is deprecated at P:\ +test\test.pl line 12. Use of uninitialized value in substitution (s///) at c:/Perl/lib/AutoL +oader.pm line 40. Use of uninitialized value in concatenation (.) or string at c:/Perl/l +ib/AutoLoader.pm line 41. Can't locate auto/main/.al in @INC (@INC contains: P:\test\_Inline\lib c:/Perl/lib c:/Perl/site/lib .) at P:\test\test.pl + line 12

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re: Inline::C callbacks to Perl
by liverpole (Monsignor) on Nov 11, 2005 at 21:21 UTC
    Yes, I think it's because in the line:
    setCallback( \&calledBack );
    the reference to the subroutine is being assigned to a temporary SV, which then goes out of scope (since it doesn't know the C program is still using it).   Then when C tries to use it, the thing it was pointing to is no longer there.

    So if you try this instead:

    my $psub = \&calledBack; setCallback( $psub );
    you should get the results you want, as the subroutine reference now exists in the still persistent, lexically-scoped "$psub" to which the SV "g_callback" points.

    It's a really good question.

      I agree with what [id://liverpole] is saying.

      What is happening is that the SV that is holding the reference gets destroyed. Storing it in a variable leads to the same problem. (When the variable goes out of scope that is).

      The proper way to prevent this from happening is to increase the reference counter of the code-SV. (Since that will prevent the reference counter of the (temp) variable to become 0. Meaning Perl won't destroy it.)

      (You can do this by using SvREFCNT_inc(code);. You can read more about the function/macro in perlapi)

      Update: changed wording

        Spot on, thanks. Incrementing the ref count in setCallback sorted me right out.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Inline::C callbacks to Perl
by philcrow (Priest) on Nov 11, 2005 at 21:14 UTC
    I'm not an expert on Inline::C, but I do read the inline mailing list. It's active, someone there will likely respond.

    Phil