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
