managing limited resources through GC (was: continuation efficiency)

[Michael Livshin]

address@hidden (Thomas Bushnell, BSG) writes:

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

nice.  one small thing your analisys is missing, though: the GC is
never *obligated* to free all unreachable objects.  GC's objective is
not to call destructors, it's to provide the illusion of unlimited
memory.

so a nicer solution would be a way to tell: "hey GC, see this object?
it holds a limited resource.  please ensure that it is reaped as soon
as it's unreachable".  for the current Guile GC, that would be a
no-op.  for a generational GC, it would be some way to tell it to
never "age" an object.  but any GC suitable for use with Guile has to
be conservative, so you run the risk of some unreachable objects never
dying anyway!

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

???

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

oh, I really don't know.  this attitude ("let's pretend that the
outside world is nice and let's treat the (quite expected)
manifestations of its not-niceness as exceptions") resembles the
attidude of an ostrich that hired a lifeguard.  and the lifeguard
appears only when the ostrich sticks its head into the ground. ;)

such a manner of using external resources works, but it's not using
those resources a reasonable way.

-- 
Make sure your code does nothing gracefully.