[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: continuation efficiency
From: |
Rob Browning |
Subject: |
Re: continuation efficiency |
Date: |
29 Jul 2001 16:46:50 -0500 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
(This message never made it out on 10 Jul 2001 11:28:16 -0500 due to
problems with postfix's postdrop, so I'm re-sending it now. Also, I
think issue has probably already been settled, so consider this
mostly useful for historical reference...)
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 automatically.
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
- Re: continuation efficiency, (continued)
- Re: continuation efficiency, Rob Browning, 2001/07/08
- Re: continuation efficiency, Thomas Bushnell, BSG, 2001/07/08
- Re: continuation efficiency, Marius Vollmer, 2001/07/09
- Re: continuation efficiency, Thomas Bushnell, BSG, 2001/07/09
- Re: continuation efficiency, Rob Browning, 2001/07/10
- Re: continuation efficiency, Dale P. Smith, 2001/07/10
- Re: continuation efficiency, Thomas Bushnell, BSG, 2001/07/10
- managing limited resources through GC (was: continuation efficiency), Michael Livshin, 2001/07/11
- Re: continuation efficiency, Rob Browning, 2001/07/11
- Re: continuation efficiency, Marius Vollmer, 2001/07/22
- Re: continuation efficiency,
Rob Browning <=
Re: continuation efficiency, Jim Blandy, 2001/07/08