Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 06:11 PM 8/2/00 -0400, John Tobey wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > At 05:39 PM 8/2/00 -0400, John Tobey wrote:
> > > > > A scalar is made an object via a call into the perl
> > > > > library. The scalar is marked as an object and stuck into a
> > > > > package. Attached to the scalar is a pointer to the native
> > > > > object, a pointer to a generic dispatch routine, and a
> > > > > pointer to the native destruction routine for the object.
> > > >
> > > >Perhaps add a native mark routine, if we are really
> > > >GC-agnostic.
> > >
> > > When the object finally goes out of scope then we call the
> > > destroy method and assume that everything hanging off the object
> > > pointer is gone. That only leaves the perl bits to clean up, and
> > > we know about those.
> >
> >Don't assume that the Perl interpreter is the sole root of
> >accessibility. Maybe some other language has 'us' (i.e., the
> >interpreter) as an object and needs to mark all its own objects
> >that we refer to for the benefit of its own GC.
>
> Right, and I'm not. The destroy method is really the perl "I'm done
> with you" method. Perl calls it when the object falls out of scope
> and perl would call the cleanup code for it. The code that owns the
> object can then do whatever it needs to. The function should be
> renamed, I agree.
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.
I still think foreign objects need a MARK method in addition to
DESTROY (or RELEASE, whatever).
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
