On Wed, 14 Feb 2001, Matthew Gillman wrote:

> 1) "Embedding Python seems to require that you link in all packages that
> Python *could* use." I'm not an expert on Python, but certainly the
> C/Python API allows you to import and reload modules (into a Python
> interpreter embedded in C/C++) at runtime - so presumably you could do
> this with Inline.pm?

You could -- if things worked the Right Way. In Windows, actually, you
can, but not in Unix. Here's why: (warning: long explanation)

When you load an extension module in Perl, that extension uses the Perl
API. Any Perl functions you use from C must be resolved at run time. Same
for Python extensions. The problem is that when you embed Python inside
Perl, and Python tries to load a dynamic library, that shared library
can't "see" any symbols from Python. It can only see the Perl symbols.
Why? Because in Unix, when you load a dynamic library, its symbols are not
by default made available to subsequently loaded libraries. Windows does
make library symbols available, so on Windows this isn't a problem.

The same problem exists in the other direction. If you embed Perl in
Python, Perl won't be able to DynaLoad anything because only the Python
symbols are visible.

In Perl this can be solved (and will be in a few days). DynaLoader allows
you to overload a sub called dl_load_flags -- if it returns 0x01, then the
module is loaded in such a way that it is visible to subsequently loaded
modules. Note that some Unixes don't support global dynamic loading, so
for those platforms you will never be able to import C extensions using
Inline::Python.

> 2) What's it like when run through Purify? Just curious :-)

I don't know. I'm guessing Purify is a memory analyser of some kind?

> I haven't used it myself, but it certainly looks interesting. With the
> project I was working on, the C++ called the embedded Perl/Python
> interpreter, which used specially-written modules; it was envisaged that
> these scripted modules would (for speed) probably have to, themselves,
> call C or C++ routines. So you can see that things started getting a bit
> hairy :-) But we never got into that level in the end.

Thank goodness! :)

> Thanks.
>
> Matthew Gillman

Later,
Neil

Reply via email to