Well - if anyone is interested - I actually got it working.
The key for doing callbacks into the parent perl interpreter was building perl with
-Dusemultiplicity. So now I am happily able to have perl -> C++ threaded -> perl.
THanks to those you helped.
Cheers.
On Sun, Aug 26, 2001 at 04:36:38PM -0400, Sam Tregar wrote:
> On Sun, 26 Aug 2001, Piers Harding wrote:
>
> > I have tried doing direct ( unprotected - no locking ) calls back into
> > the parent interpreter - this barfed badly.
>
> Yup, that's no good.
>
> > 2ndly I have tried the approach of creating separate interpreter
> > instances perthread ( usemultiplicity ) which appears to work fine
>
> Caution: falling rocks. Some things will work, some things will flatten
> your car.
>
> > except that I am still having trouble sorting out the argument stack (
> > but that is probably ignorance )
>
> This shouldn't be any different than the normal Inline::C case. Maybe you
> could put together a small test case that demonstrates your problem?
>
> > 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.
>
> This is the path I would recommend. The performance problems will be easy
> enough to understand - while one callback is executing other callbacks
> will be blocked. As long as you're careful with what you put in a
> callback you should be able to manage.
>
> > 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 ).
>
> Sounds... experimental. I'd wait for the final product before cutting and
> pasting.
>
> -sam
>
