Chels has asked for the wisdom of the Perl Monks concerning the following question:

Hi, We are facing some problem while calling perl from C with multiple threads. We created two threads and then created one perl interpretor instance each in that thread's context (C-> perl XSUB calls). After that, we tried calling one common perl subroutine from both the threads with its own perl interpretor instance. We are getting some strange results. Sometimes it's dumping. Some times it's giving error like "Modification of a read-only value attempted at test.pl line 3". However, if you see the code, 3rd line is open brace only. package pkg1; sub testsub { my ($Data) = $_[0]; # some computation goes here. } Basically the local stack contents getting modified it seems. We've not compiled the perl with -DMULTIPLICITY option. Environment HP-UX 11.x Can any one suggest something. Thanks, Poornachandran SM

Replies are listed 'Best First'.
Re: Multiple perl interpretors....
by AgentM (Curate) on Dec 11, 2000 at 21:25 UTC
    Read my previous thread on this hot topic. <perl.h> does not seem nor does it claim to be thread safe! You will have to use ONE interpreter coupled with a mutex and throw C enywhere in between. I repeat- perl.h is not thread-safe (hell, it doesn't even provide a basic model for the beginnings of thread-safeness) and thus you are left with ONE interpreter and a mutex. Sorry to burst your bubble. This is specific to Perl as of 5.005. If you believe this NOT to be the case, please respond since this situation interests me, too, but I don't think that the perlembed interface has changed since 5.0.
    AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

      I haven't looked at this in detail, but I believe that if you configure Perl to not do any threading, be embedded, and allow multiple interpreters, then you should be able to have a pool of multiple interpreters that are shared between threads so long as no two threads try to use the same interpreter at the same time. I recall a successful report of this on one of the mailing lists I am on.

              - tye (but my friends call me "Tye")
        Hi, If you can give some more explaination on your view, it would be helpful to us in resolving the problem. Thanks.
        That's nice, but the perl.h interface is lacking in that its own API basically restricts calls to one interpreter. That's the only problem. You can use only CERTAIN function calls to the interpreter so it is missing threadness in that sense. I think that the API itself needs some reworking. Basically, you are restricted to executing arbitrary code in an adhoc manner which displeases me. It is possible to circumvent this, but, as you say, you must recompile Perl with various options which obviously does not change the Perl C API to take advantage of this. I've been bustin my nuggets on this shit for weeks. I'm working on a hefty program that you'll all enjoy. I got around the thread issue by simply using one interpreter throughout the program which I lock with a mutex as necessary. I can retrieve the values processed by call with other muteces. It's brutal but the API is lacking, so there's little I can do. Please, if you have any other info or corrections on this, feel free to respond since this is important to me!
        AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
Re: Multiple perl interpretors....
by mikfire (Deacon) on Dec 11, 2000 at 21:42 UTC
    And I quote from perldoc perldelta for perl-5.6:
    Perl 5.005_63 introduces the beginnings of support for
    running multiple interpreters concurrently in different
    threads.
    
    There is more, but it is largely greek to me - I don't play with this stuff. I will point out that this is, according to the docs, experimental and the interface may change.

    mikfire