Re: continuation efficiency

[Rob Browning]

address@hidden (Thomas Bushnell, BSG) writes:

> The danger supposedly avoided by using unwind-protect (in Lisp) or
> dynamic-wind (in Scheme) around the call to proc is that an error will
> happen, we'll totally abandon proc, and then the port will be "left
> open" forever and needlessly.  That's a fake worry.  A correct system
> will gc the port object as soon as this happens, if indeed, we have
> totally abandoned proc.

Unless I'm misunderstanding you.  I disagree.  A "correct" system
might not GC the port object until much later, if ever.  It might
defer the GC until later if it has plenty of RAM in order to increase
performance, and if the app doesn't generate much further garbage, the
GC might not clean up the port until the whole app quits.  Heck, I'm
not even sure there's anything that guarantees that if the app quits
with garbage still available, the GC can't just declare it "collected"
by exiting the process on systems that automatically reclaim the app's
heap.

In general, I've never heard of GC timing guarantees in a "normal" GC.
And most of the timing guarantees I do hear about are concerned with
making the cleanup incremental, or real-time, or bounded-time, or
whatever.

Am I just misreading you?

> Can you give an example where call/ec and escape-protect are needed
> where you are *not* positing in advance that the gc system is broken?

I certainly may be wrong, but I have the strong feeling you're
oversimplifying the problem here.  If nothing else, I've dealt with
enough "real-world" hardware and protocol specs to doubt seriously
that you'll have situations and protocols where it's even semantically
possible to always DTRT.

That doesn't mean that I don't think there may be a better solution to
some of the current problems that call/ec, but I'm also not sure that
some of these problems can be so easily de-crufted.

I'd love to be wrong though :>

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD