Re: Phil meet y-devel; y-devel meet Phil

On Thu, Jul 22, 2004 at 06:04:58PM +0100, Mark Thomas wrote:
> ISTR there isn't a way for clients to manually destroy an object they
> created (unless Andy wrote a "destroy" method when he fixed up the object
> system).  An exercise for someone wanting something to do to poke around
> the tree?

Never got around to it. Implementing a wrapper to objectDestroy in the
server is trivial (I'm inclined to move the code from objectDestroy
into the Object::DESTROY method, and make objectDestroy itself just a
method call to DESTROY; estimated time, two minutes). Teaching libYc++
when to send the message is hard; the interface is tricky.

> > since there is no way to guarantee
> > it has really forgotten it.  We might need an assassin function to kill
> > those clients which have too many apparently unused server objects, but
> > this should only be used when there are insufficient resources on the
> > server (like the Linux OOM killer).  Allowing for the server to
> > unilaterally delete objects which may still be valid is too risky.
> 
> I think this is our only choice.  It's currently what X does.  There was a
> bug in mozilla firebird (back when it was called firebird) that meant they
> had a pixmap leak.  Every few days my browser (which I never close) would
> implode.  After a bit of poking around, I noticed that before the
> implosion, X was coming up to using nearly all my RAM, afterwards, it was
> back to its usual self.

Around the time of gtk 1.2, there were a lot of gtk pixmap themes
being written that would leak like anything, because theme authors
can't code. Since they leaked enthusiastically into every gtk
application's pixmap space, the server's memory space would get full
of holes and most of it could never be reclaimed (there's no sliding
heap on glibc systems).

> > Side note: Since the client and server are separated by the protocol, a
> > memory leak in the client can never be detected by the server.  It's
> > also pretty much impossible to detect a memory leak in a running program
> > when this is not the case.
> 
> Actually, I wouldn't be surprised if detecting true memory leaks was
> halting-problem equivalent.

I think it's actually worse. You need to know which allocation objects
will not be referenced again in the future, along all possible code
paths - you have to solve the halting problem an infinite number of
times.

> > > One simple way to tell is to keep a client reference count for each object,
> > > which would only keep track of how many clients hold references to an object.
> > > When that count reaches zero (and you might have a server flag which would
> > > keep this from being garbage collected), the resource could be freed.  This
> > > way, the GC would only need to be run each time a client disconnects,
> > > reducing overhead.
> >
> > I am reasonably sure that for those objects which can be destroyed it
> > will only be possible for one client to have a reference to that object
> > anyway.
> 
> Not entirely.  We need a way to implement what Gtk calls Plug and Socket
> widgets.  The easiest way is to allow a client to make a whole bunch o'
> widgets and pass the oid of the topmost widget safely to another client,
> which can then pack it inside its own widgets wherever.  This opens a
> whole can of worms regarding what to do when each client exits (at the
> very least, they need to be told about it).

Bweh. I'm not at all sure that's a sensible approach. It would be
easier to have seamless embedded windows.

> For now at least, we don't need to worry about wayward clients allocating
> too much.  Long term, the using-too-much-resources-killer is probably our
> only defence from being targeted by the linux OOM killer, or whatever the
> equivalent is on whichever platform.

I'm not sure this problem is worth solving. If the user is going to
use up too much memory, let them. It's their own damn fault. We can
provide a system of ulimits for those users who want to control unruly
applications (developers, mostly) and stop there.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBAAzrlpK98RSteX8RAqM4AJ4g7+W6KaKvvUWeehmZq3Kc3Ic/bACeO4dq
lmtFdTMH5pCbOHv7shsV5iU=
=+T2d
-----END PGP SIGNATURE-----