On Sun, Aug 06, 2000 at 01:24:10AM -0400, Dan Sugalski wrote:
> John Tobey wrote:
> > Picture this. A Lisp (or Java, ...) structure holds a Perl
> > interpreter. A Perl variable holds a reference to the Lisp structure.
> > Structure and interpreter become inaccessible to all threads. Perl
> > will never know it's done with the Lisp structure, neither Perl nor
> > the structure will ever be collected, and we will have defeated
> > mark-and-sweep.
>
> FWIW, this isn't a case I'm worried about. If an embedding program doesn't
> explicitly destroy an interpreter, then its reasonable to assume that the
> interpreter's not dead and shouldn't be cleaned up after--if someone's
> leaking interpreters then, well, they've got bigger problems than the odd
> foreign object. :)
I'm not so sure I agree with this. Other-language modules in a large
application might have good reason to use a private Perl interpreter
within an encapsulated interface.
Anyway, my point is valid for data structures other than
interpreters. Lisp variable `perl-int' holds an interpreter, which
contains a by-Perl-unreferenced anonymous scalar, which contains a
Lisp structure, which contains a reference to the scalar.
------------ ---------------------
| | | |
| Perl -------->| SCALAR(0x8335bfc) |
| | | | |
------------ --------|------------
| ^
| |
V |
|-----+--|--|
| | | |
| car | cdr |
| | |
|-----+-----|
If Perl uses reference-counting as its only garbage collection, this
loop will have to be broken explicitly. But if we anticipate possibly
implementing mark-and-sweep, our mark routine should call Lisp's mark
routine on those Lisp objects we still reference, which would allow
those we don't to be collected.
-John
