Do you know where your variables are? | |
PerlMonks |
Re^4: Perl crash during perl_cloneby perlmonk1729 (Acolyte) |
on Oct 28, 2010 at 06:01 UTC ( [id://867918]=note: print w/replies, xml ) | Need Help?? |
if the callback gets triggered at a point in teh application when the "wrong" interpreter has the cpu, then it fails
There are only two threads/interpreters and the thread that cloned an interpter does nothing else but wait for the right event to invoke the callback. So, bit confused what could be the 'wrong' interprter The solution I'm afraid is to re-think your methodology. If you can describe why you are starting a second interpreter, we might be able to see a solution. Infact, I did not know anything about interpters or cloning when I started this project. I learnt how to modify the SWIG generated wrapper to register the callback (RegisterCB in my example): I cache the perl sub reference and instead register a proxy C method (InvokeCB) into the C-api interface. When an unrelated thread (BGThread) called InvokeCB, it sets up the call-stack properly to call perl subroutines and then calls the sub via the cached reference. However, the "call_sv" would always crashed - 100%. Then I stumbled across the perl_clone() and found many posts that claimed it was required because BGThread cannot call code into an interpreter it did not create (i.e perl.exe). Having a cloned interpter allowed call_sv to work reliably..until my latest problems. You can see this link about my previous experiences that got me here. http://markmail.org/thread/cjbhybjfikuirvud ps: I'm in asian timezone, so responses may seem to have a 'lag'.
In Section
Seekers of Perl Wisdom
|
|