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.

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...;
}
[download]

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.