lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

On 20/08/09 14:05, Matthew Wild wrote:

On Thu, Aug 20, 2009 at 1:56 PM, Lawrie Nichols<lawrien@gmail.com>  wrote:

Hi all

I've got a problem trying to use weak-referenced tables. While they perform
as described, it's not quite what I had hoped for. The problem is really
that entries in such a table (be it weak-keyed or weak-valued) remain
accessible until the underlying object is marked (or unmarked ??) by a GC
cycle.

So, my questions are:

1) is it possible to force the GC to just mark an object (or unmark it ??)
without running a full GC cycle ?
2) if the answer to 1) above is yes, then is it possible for table
keys/values to 'hide' the table entry if their underlying object has been
marked to die ? Currently, is seems that such tables will only remove
entries as part of a GC cycle.


This is usually done by setting that field of the table to nil,
whether it is weak or not. The GC makes no guarantees (as far as your
code is concerned) about when it will run, mark, or collect objects.

The GC just does the "right thing", if you're having problems, it
seems like you are using weak tables for the "wrong thing". If I
misunderstand, could you explain your use a bit more?

Matthew
Basically, I wanted to use them as a cache for data stored in other tables in order to avoid having to call a costly lookup function for each data access. The problem is that even if the data in the underlying tables is updated or removed, the data in the 'cache' table is not 'invalidated' until after a GC cycle. 

So, I end up with a situation where I need to either:

a) abandon the use of the cache, and simply do the lookup each time.
b) run the GC after any modification to one of the underlying tables in order to remove the cache entry in the cache table; this is unappealing as thousands of entries could be updated in the underlying tables. b) do some kind of manual check on the cache entry to see if it still matches the data in the underlying table. I suspect this would degenerate into nothing better than a). 

I'm open to any suggestions !!

Lawrie