Re: Memory leak?

["alex.mania@..." <alex.mania@...>]

On Thu Jan 31  0:47 , 'Mark Meijer' <meijer78@gmail.com> sent:
> Sorry, I didn't see the last two replies (by Hans and Alex resp.)
> until I posted my previous one.

>That would be sufficient, the way I currently understand it. But what
>I was getting at, is the fact that (in my example) the entire table
>contents (of the bar table) will remain in memory, simply because that
>table (bar) has once briefly been used as a key in another table
>(foo). In this case, the "entire table contents" is just a single
>string, but what if it was more than that? If Lua's garbage collector
>considers bar as being referenced for as long as that key is
>"remembered" by the foo table, even after assigning nil to that key,
>then the "problem" becomes a bit more pronounced. Don't know if that
>is how the garbage collector sees it, but I suspect so.

I'm guessing you saw in the reply that the GC can collect the keys =). So the
loss is only minor - it's only the 28 (or 32, depending on kludge factor) bytes
for a Node. The key can still be collected, just not the node.

>But correct me if I'm wrong in assuming that next() only benefits from
>these "remembered keys" during table traversal. This should have no
>impact on the implementation of something like collectgarbage("keys").
>No need for flags and whatnot. As long as it's clear (i.e. documented)
>what it does, sothat nobody would get the idea that they can and
>should call collectgarbage("keys") *during* table traversal...

Yes, that would work. I can't see it being implemented though for the number of
bugs it could introduce in seemingly good code. Just think, a function that'd
break any pairs() loop it's inside of, no matter how nested the call to this
function is. And not just break the ordering, but make the loop throw an error -
something a normal loop would never do.