My post on perl5-porters didnt get any reponses.

If you supplied a similarly minimal amount of information there as here, that is not surprising. It will be very difficult to reach any definitive conclusions based up such scant information.

As I said in a previous thread, if you don't post representative, working code to demonstrate your problem, then anyone attempting to help you has to try and re-create your scenario from your very brief description. And that really is asking far too much of volunteers.

I notice that you actually did post some code in a previous thread, but you did so as replies to yourself, which means that no one else ever received a notification of those posts.

Ie. It is probable that none of the monks involved in that thread, including cdarke who actually attempted to reproduce your failing scenario, almut nor I were even aware that you had posted it. I certainly wasn't.

Attempting to read between the lines of the information you have provided here (and in your related previous threads), you are attempting to call a coderef (callback)--in an interpreter/thread that you spawned yourself from within C--that was passed into your C code from another interpreter/thread spawned by Perl.

With the best will in the world, that is never going to work reliably. I'd be amazed if it ever worked at all. Though from your description it appears it has and does--so color me amazed.

The only way I can see it working sometimes and not others, is if your code is dependant upon which thread happens to be running when the callback is made. That is to say, if at the instant the asynchronous event (socket read completion?) that triggers the callback, the same thread that passed the callback coderef to your C code happens to be running, then it will likely work. If however, the other thread happens to be running, then it doesn't.

If this is the case--which should be fairly easy to verify by having your C/XS code log the current thread id: a) when it is passed the callback coderef; b) just before it invokes that callback. And if it is the case, the resolution would be to ensure that when your C-code creates it's own interpreter/thread, it follows the exact same steps as used by threads::create(). Of course, in reality, it would almost certainly be easier to allow Perl to that for you.

But then comes the question of why you feel the need to create a new interpreter in the first place? And for anyone to be able to understand that, you will have to describe the overall functionality and methodology of your complete application in far more detail than you have to date.

But...there is a simpler route. Take your 10MB of C code out of the equation. Once you have a reliable demonstration of passing in a Perl coderef to C code, which is subsequently called back at a later time--possibly triggered by a timer--in a multi-threaded environment, it should then be pretty easy to port that back to your real code.

Perhaps based on the code you posted in that other thread, create a minimal, runnable example of the callback scenario you require. But do it in a single post--as a reply to someone other than yourself.

Preferably do it as a single file using Inline::C to make it easy for others to download and run. I for one wouldn't know what to do with all the separate files you posted in that other thread, in order to get to the point where I could actually run the code.

If you cannot see how to do it as a single file using Inline::C, then at least wrap the multiple files up into a proper CPAN -style distribution and make it available somewhere, so that others can use CPAN to build and test it.