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.

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.