XS/C, threads, and calling call_sv() with a code ref

[stevieb]

Hello fellow Monks,

I am experiencing an issue with some C/XS I'm trying to get working. I will explain what I'm trying to do, how I perceive what the code is actually doing and a bit about what's happening. I'll then show the Inline::C code, the output, some gdb debugging output. Unfortunately, unless you have a Raspberry Pi, there's no way you can repro this successfully.

What I'm trying to do:

I have an interrupt routine for a GPIO pin on the Pi. This interrupt routine (ISR) is spun off into a separate C++ thread, and to facilitate the ability for the user to use a Perl subroutine as the callback/interrupt handler, I'm trying to pass in a code reference, and have the C/XS execute that sent-in-as-a-param code ref.

What is the code doing?:

I set up a function in main called cref_handler(). I then initialize the RPi, configure the appropriate GPIO pin, then set the interrupt on that pin, passing in a reference to the mentioned cref_handler() routine. The interrupt handler (the code the coderef points to) is to run any time the specified pin goes LOW (ie. 0 volts). Both the interrupt setup and the actual interrupt handler that executes the code in the coderef is written in C and passed along to an external library that dumps the ISR into its own thread.

What the hell is happening?:

The callback code simply prints to STDOUT. Once the script is run, I may get a few printouts when shorting (ie. turning LOW the pin), sometimes I don't. In all cases, it eventually leads to a SEGFAULT. Sometimes after a microsecond, sometimes after a second or two.

I'm not an expert C coder by any stretch, so I believe what may be happening is that the threaded interrupt code isn't handling the global C variables I've set up, or perhaps it's the way I'm using some of Perl's internals wrong (eg: PerlInterpreter, PERL_SET_CONTEXT etc), or the way the interruptHandlerCref() XS code is laid out.

Summary:

I'd greatly appreciate it if those experienced in these XS/C matters could have a look and see what I'm doing wrong here, if its possible without having to actually run the code (I truly apologize for that inability). I'm thinking it's my inexperience with C, or misunderstanding how the whole background threads thing is handled here.

Code:

use warnings;
use strict;

use RPi::Const qw(:all);
use Inline ('C' => 'DATA' => libs => '-lwiringPi -lrt -lwiringPiDev -l
+pthread');

my $continue = 1;
$SIG{INT} = sub { $continue = 0; };

sub cref_handler {
    print "cref handler\n";
}

my $cref = \&cref_handler;

init();
pin_mode(3, INPUT);
setInterruptCref(3, EDGE_FALLING, $cref);

my $running;

while ($continue){
    print "running\n" if ! $running;
    $running = 1;
}

__DATA__
__C__

#include <wiringPi.h>
#include <stdio.h>

void init (){
    wiringPiSetupGpio();
}

PerlInterpreter* mine;

SV* perl_callback_cref;

void interruptHandlerCref(){
    PERL_SET_CONTEXT(mine);

    dSP;
    ENTER;
    SAVETMPS;
    PUSHMARK(SP);
    PUTBACK;

    call_sv(perl_callback_cref, G_DISCARD|G_NOARGS);

    FREETMPS;
    LEAVE;
}

int setInterruptCref(int pin, int edge, SV* callback){
    mine = Perl_get_context();
    perl_callback_cref = callback;
    int interrupt = wiringPiISR(pin, edge, &interruptHandlerCref);
    return interrupt;
}

void pin_mode (int pin, int mode){
    pinMode(pin, mode);
}

Output:

running
cref handler
cref handler
cref handler
running
dler
running
dler
Segmentation fault

I am perplexed as to how the running line is printed numerous times, given that it should only print once, at the onset after everything else is done. This is what leads me to believe something is going very wacky with the threading somehow...

Debug output (snipped for brevity):

$ gdb perl

GNU gdb (Raspbian 7.12-6) 7.12.0.20161007-git

(gdb) r int.pl

[New Thread 0x76af7470 (LWP 26138)]
running
cref handler

Thread 1 "perl" received signal SIGSEGV, Segmentation fault.
0x000c09ec in Perl_pp_and ()

(gdb) bt
#0  0x000c09ec in Perl_pp_and ()
#1  0x000c0434 in Perl_runops_standard ()
#2  0x000500a4 in perl_run ()
#3  0x0002ab50 in main ()

The backtraces are consistently different, fwiw, but mostly they are relatively similar. I can repro several times if necessary if it'll help.

Cheers,

-stevieb

[dave_the_m]

If I understand you correctly, you have two different threads (the main perl interpreter, and a C++ thread activated by an interrupt) both accessing the same perl interpreter. This is a big no-no, and corruption is going to ensue.

The basic model of perl's current threading implementation, ithreads, is that each OS-level thread is given a separate perl interpreter, so that if they run in parallel, they can't stomp on each other's data. The perl internals just aren't designed for concurrent access - there are no internal locks protecting each SV and/or critical code sections.

Dave.

[stevieb]

Thank you Dave for your feedback.

In essence, if I'm hearing you correctly, you're saying that what I am trying to achieve is not possible.

If I'm right in assuming that, I will abandon my attempts. That said, is there any way to spin off a separate interpreter who can decipher the same variables through XS? I'm drawing at straws here, but would like final conclusion, good, and/or bad so I can lay this to rest.

[dave_the_m]

In essence, if I'm hearing you correctly, you're saying that what I am trying to achieve is not possible.

Not all all; it just needs to be done differently. Off the top my head:

Use two perl-level threads: the first is your main program, the second is created with threads->new(...). The main thread does whatever normal activity you want to run; the second runs a loop which calls an XS function which blocks waiting for an interrupt:

use threads;

# interrupt thread

sub handler {
    while (1) {
        XS_wait_for_interrupt();
        print "got interrupt\n";
    }
}

threads->new(\&handler)->detach();

# main thread

my $continue = 1;
$SIG{INT} = sub { $continue = 0; };

while ($continue){
    ...do_work...;
}

How the XS function waits for and wakes up when an interrupt is received depends on the details of how interrupts are implemented on the rPI, about which I no nothing. But maybe have something set and release a mutex, and have XS_wait_for_interrupt() block on the mutex.

If the interrupt perl thread needs to interact with the main thread in some way, then that depends a lot on how they should interact. For example, using threads::shared to pass shared data beteen the threads. Or if the main thread's role is mainly to do tasks based on events, then maybe use one of the various event modules available on CPAN (about which I know very little), where the interrupt is one of the events the main thread can handle.

Dave.

[BrowserUk]

You might find a solution here. Its a long subthread, and the good stuff is towards the end, but (and you'll get this later) you'll need the earlier context.

The best (most complete) version of the test code is here.

The basic idea behind the mechanism is that you call a setup() function from each thread you wish to call back to, passing the callback address, and implicitly, the interpreter context. That setup() function records both, and when the callback occurs, it (temporarily) switches to the appropriate context before calling the callback, and then switches back after.

I haven't touched that code, or any derivatives of it in at least 5 years, nor much perl threading in at least 2. The last version of perl I installed was 5.20! So I am unaware of any changes since (and actually before as I never made it past 5.16 for anything real).

What I'm saying, is if you try the code, I may not be much help in support of it :(

But it might solve your problem if no other solution is presented.

Another (off-the-cuff) possibility would be to spawn a new perl thread to handle the callback and then have it loop over a short sleep. Something like that, but I haven't though it through.

[NERDVANA]

If you *want* a threaded perl experience, then go with the earlier answers. But if all you really wanted was event-driven callbacks, you could have the C thread just write a byte into a pipe (which you're holding both ends of), then have the main perl interpreter read from the pipe and dispatch to callbacks right from perl-space, in a single-threaded manner. You can use something like select() or AnyEvent to wait for data to arrive on the pipe.