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

On Thu, 22 Jul 2004, Andrew Suffield wrote:

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

True, we don't know the future input yet, and the HP assumes that we do.
I was basing my conjecture on the basis that "Will line X of the code be
run" is known to be HP-equiv, extrapolating that for all the lines where
the allocation object in question is touched.  Regardless, it can't be
done.

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

I think that's going to amount to the same thing.  The two applications
will need to know when each other vanishes (presumably they're going to
want to do something about it), and they might also interact in other ways
(though in that case they'll have some other notification mechanism
anyway). ... Maybe you're right.  I shall dwell on this subject some more.

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

Well, given the choice between Y killing the wayward app and the OOM
killer killing Y, I think I'd prefer the former, even if it's slightly
harder.

For now at least we can be lazy.

Regards,

  Mark.
-- 
|| Mark Thomas
|| efaref.net
||
|| What do you mean my birth certificate expired?