Re: continuation efficiency

[Rob Browning]

address@hidden (Thomas Bushnell, BSG) writes:

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

Again, perhaps I'm misunderstanding, but this seems like a rather
selfish (app-wise) way to handle the issue.

Say I'm a Scheme client and I use this policy, but everyone else is
written in C and explicitly de-allocates the server connection when
finished with it.  I might often cause other clients to start failing
long before I try another connection myself and actually realize that
I need to run a GC and free up my dead resources.

In short, IMO waiting until my next connect fails doesn't seem like a
very friendly way to handle a sever-side resource from a client.

It sounds a little like planning to onl call "free" once all swap is
exhausted and your own mallocs start failing.

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