Thanks for the reply -
I have tried doing direct ( unprotected - no locking ) calls back into the parent
interpreter - this barfed badly. 2ndly I have tried the approach of creating separate
interpreter instances perthread ( usemultiplicity ) which appears to work fine except
that I am still having trouble sorting out the argument stack ( but that is probably
ignorance ) - the problem with this is that there is no shared global data across the
interpreter instances thus being a bit limiting for a solution.
Ideally I would like to have multiple threads calling back into the parent
interpreter, so that all the usual concepts of global and shared data are available,
but I am unsure as to whether this is possible, and what performance problems this
might give if you have to lock each callback.
I have tried looking into the code behind the new mod_perl for Apache 2.0 - this is a
bit over my head, and is also experimenting with modifications to perl itself (
things called Solar variables ).
Cheers.
On Sun, Aug 26, 2001 at 02:46:07PM -0400, Sam Tregar wrote:
> On Sun, 26 Aug 2001, Piers Harding wrote:
>
> > (1) Wrappering the libraries as a whole is possible - I have done a
> > quick hack, but creating a callback into the perl interpreter from a
> > threaded C++ library is proving very difficult indeed ( well at least
> > it is for me ).
>
> Can you describe your difficulties? What approach have you taken?
>
> One way you could go would be to treat the Perl interpreter as a
> non-thread-safe resource and put locks around every access to it. As long
> as you can be sure that two threads can't access the interpreter at the
> same time, you should be fine.
>
> Alternately, you could build a treading Perl and attempt to create a Perl
> thread for each C++ thread.
>
> Since threads are considered experimental I would probably choose the
> first option, but I imagine there are reasons you might try the latter.
>
> -sam
>
