[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: continuation efficiency

From: Thomas Bushnell, BSG
Subject: Re: continuation efficiency
Date: 10 Jul 2001 17:08:17 -0700
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Rob Browning <address@hidden> writes:

> 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.

Ah, yes this is a good problem area.

Let's be careful to understand exactly what the problem is here before
jumping to a conclusion about how to solve it.

There is a resource, being held by the server.  That resource fills
up, but we don't know, and we never schedule a local GC in time, with
the result that the server starts giving errors.  (Thinking
specifically here of the kind of thing that Dale Smith ran into which
me mentions in his followup.)

So first off, what would the Right Thing be?  It would be for the
server's resources to properly part of the big global resource pool,
and once it nears running out of resources, it should schedule a GC,
which would indeed free up the useless connections still hanging
around on the local side.

So that's the Right Thing, but of course, the actual protocols in use
don't do it.  How can we get correct program behavior, given that the
protocols don't properly support GC?

The first and most obvious solution is for the connection creation
code to itself notice that a connection attempt has failed for lack of
server resources, and schedule a GC itself in the hope of making more
server resources available.  

The second and not-quite-optimal solution is for the client to
occasionally schedule "possible GC" points: that is, to have a
function which one can call that says "this object is very likely free
now, please see if it really is".  

> 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.

Oh, I'm *deliberately* over simplifying.  But Scheme's hallmark is

The Schemey solution to problems like this is *NOT* to have an "escape
to PL/1" function.  Or even "escape to Lisp".  And that's what call/ec
+ escape-protect is.  

The Schemey solution is to think of ways that preserve the fundamental
elegance of the language rather than thinking of ways that attach
warts to make certain things easier.

In the specific case of a server that is denying connections because
one isn't closing idle connections on the client, the ideal solution
for the client is to detect that as a resource exhaustion (just like
an out-of-local-memory resource exhaustion), and GC to free up
resources, just like always.

This requires exporting to the user a (garbage-collect) function,
which is a wart indeed, but not a huge one.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]