 |
lua-l archive |
|
|
||
|
On Oct 21, 2009, at 1:30 PM, Roberto Ierusalimschy wrote:
The above seems like a memory leak, as 'cache[ aPath ] = aContent' willhold everything forever. Thoughts?It is curious why nodoby is concerned with similar things happening with numerical keys. If aPath is a number, you have exactly the samesituation. Should Lua wait until the number is collected to remove thatentry from the table?
To start with files aren't generally identified by number (though I guess one could get the inode number), but be that as it may...
What seems more troubling is not the fact that string keys aren't weak (though that's at times awkward) as that string values aren't weak (though the lack of weakness for string keys is a problem for weak sets of strings even strings as values were weak).
In the file cache case, what really matters is that if the results of the file read are still in memory then there's no point in reading again. We can work around the issue with an intermediate table in the cache which is mostly accurate if we don't hang onto the results of file reads for very long. On the other hand, this means that any GC protection logic -- i.e., logic to keep the read data from going away too fast -- must now deal with the intermediate tables. We can't simply access a value from the file cache and hand it to the GC protection logic. Rather we need to hand an internal data structure from the file cache to the GC protection logic.
Mark