Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

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

by dave_the_m (Monsignor)
on Apr 25, 2018 at 21:44 UTC ( #1213555=note: print w/replies, xml ) Need Help??


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

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.

  • Comment on Re: XS/C, threads, and calling call_sv() with a code ref

Replies are listed 'Best First'.
Re^2: XS/C, threads, and calling call_sv() with a code ref
by stevieb (Canon) on Apr 25, 2018 at 21:52 UTC

    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...; }
      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1213555]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (6)
As of 2019-09-17 19:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    The room is dark, and your next move is ...












    Results (215 votes). Check out past polls.

    Notices?