* Geo Carncross [2008-02-04 18:26+0100] writes:
On Feb 4, 2008 10:17 AM, Helmut Eller heller@common-lisp.net wrote:
Perhaps a better way to deal with this is to have slime indicate what objects its holding and/or clear this buffer when it stops using them. This might better belong in a per-connection thing, and I wanted some advise on this before I started hacking on this.
That sounds like a quite a bit of work. Don't know if it's worth to bother. Presentations work also with normal (non-weak) hashtables and there is already a command to manually clear all presentations on the Lisp side.
Really? I guess it'd require saving *presentation-id-to-object* and *object-to-presentation-id* in the connection. Maybe instead a connection-closed-hook could look at the existing tables and clear off any entries that belonged to that connection. I don't know right now, I'd have to think about this more, but it doesn't seem to actually need to be that much work.
Yes, that shouldn't be so hard. But I assumed you are aiming at something like a distributed garbage collector: track all references that Emacs has and when Emacs drops all references to an object also drop the reference to that object on the Lisp side. Such a scheme could release objects before the connection gets closed. And implementing it doesn't sound easy to me.
It's just at that point, weak hash tables wouldn't contribute anything (that I can see), so it'd be a lot of code that could be removed.
One could argue that SLIME shouldn't unnecessarily keep objects alive. With weak hashtables it's possible to release more objects at the price that some presentations no longer work. But the presentations for objects that are alive anyway (e.g. because some application needs them and usually the important objects) still work. I think that's a reasonable tradeoff.
Helmut.