gc issues

[Victor B. Putz]

>Basically, you need to announce the objects of one language to the
>other language's garbage collector.
...
>To summarize: as long as you don't create cycles involving objects
>from both languages, you only need to make sure that objects
>referenced from one language are not collected by the collector of the
>other language. If you have cycles of mixed languages, I doubt there
>is prior art integrating the GC routines.

A note:

When I was writing ePolyglot (more of a "pilot project" than a library, really)
I was able to write several little programs using eg Python objects from Eiffel
or Eiffel objects from Python (including making an eiffel extension module which
could be loaded entirely from within the interactive Python interpreter).

Basically, you had pure eiffel objects, pure python objects and then two
different sorts of "shadow" classes--Eiffel objects which held an opaque pointer
to a Python object, and Python objects which held an opaque pointer to an Eiffel
object.

In the Eiffel-holding-a-pointer-to-a-Python-object case, managing "gc" wasn't
too bad--when you accepted a reference to a Python object, you increased its
count, and in the redefined "dispose" method (from class MEMORY), you decreased
its count.  I never really stress-tested this, but the idea seemed good, and
since Python 1.5.2 (the version I used at the time) was strictly
reference-counted, you could be pretty sure that the Python object wasn't going
to vanish for no reason...

In the Python-holding-a-pointer-to-Eiffel case, there was no reference count (on
the Eiffel side) to increment or decrement, so it was trickier.  I never tried
this with ePolyglot, but one way to solve it would be to have a singleton
(CONTAINER)[ANY] which stored Eiffel objects being shadowed by Python; every
time a Python-holding-an-eiffel-pointer object was created, you could store that
eiffel object in the singleton container, preventing unwanted cleanup by
Eiffel's GC.

In any case, although it was more an exercise in Makefile hell than a truly
reusable library, I still think there are lessons to be learned from ePolyglot
(which got as far as using Haskell, Python, and Eiffel in the same
executable...).  If you're interested in multilanguage programming, check out 

http://epolyglot.sourceforge.net

with LOTS of documentation (it was an independent study for my MS)...it's not
all pretty, but you might be able to glean some useful nuggets out of it.

-->VPutz