GC leak?

[Stephen J. Turnbull]

Jerry James writes:

 > It's the only sane model for a garbage collected system where you are
 > not imposing a particular garbage collection algorithm.

Of course it's not.  "Guarantee finalization at exit" (which is what
we are discussing here) is always sane (for values of "sane" that
don't insist on minimum exit time).  "Guarantee finalization at user
request" is the only way we can test some language features (like weak
references).

 > Stop me if I'm wrong, but don't we already flush all streams on exit?
 > As long as all data has been pushed into the OS layer, it doesn't
 > matter if the OS or the application does the actual closing.  In fact,
 > I'll go so far as to claim that we don't need guaranteed finalizer
 > runs at all, as long as we guarantee that all streams are flushed.

Isn't that a claim that only streams need to be finalized?

How about closing databases?  Shutting down the stream should rollback
incomplete transactions, not commit them, but we might want XEmacs to
wait for the commit to succeed before shutting down.

How about unlocking resources?

Can we guarantee that all streams are flushed, eg, if there's a buffer
in an ELL how does that ELL ensure its buffer will get flushed on
XEmacs exit?

 > > How do Java and RnRS treat such external objects that need finalization?
 > 
 > Java doesn't.  You can't use finalizers for guaranteed cleanup
 > purposes.  You use try { ... } finally { ... } blocks to do that.

Well, Lisp is a higher level language than that IMO.

 > I don't think we need to do [anything about guaranteeing
 > finalization].

At minimum we *need* to document what our position on this is.  We do
have `unwind-protect' to match `try ... finally' in Python and Java,
but that doesn't cut it for this purpose.  We have `kill-emacs-hook'
and `kill-buffer-hook', but I think there ought to be object-oriented
rather than module-oriented ways to guarantee timely finalization.

 > > (Really, XEmacs proper should have no UI; all UIs should be clients of
 > > the editor. :-)
 > 
 > Wow, deja vu all over again.  I'll have to fork this off as a separate
 > thread, or maybe even take it private if nobody else cares,

Please fork it.  We're all adults, and know how to use killfiles.  If
the traffic warrants it, I'll be happy to reactivate xemacs-design.  I
don't want this private.  Be aware that there *may* be *some* money
available for such work.  Google SoC is one obvious avenue for those
with social or professional connections to university CS programs, and
there are also some private sector possibilities for specific features.