From: Stephen D. <sd...@gm...> - 2005-10-22 13:58:23
|
On 10/22/05, Zoran Vasiljevic <zv...@ar...> wrote: > > Am 21.10.2005 um 15:19 schrieb Vlad Seryakov: > > > Looks okay, API has changed but if we accept it, i suppose onetime > > code change is acceptable > > > > What about timed cache? I miss this (for us) important feature. The existing implementation doesn't make a lot of sense to me. You can create either a size limited cache, OR a time based cache. A time based cache has it's entries flushed based on the mtime, i.e. only when they're unused. This means popular entries will never be flushed. What you really want is for entries to have a max cache lifetime (ADP pages), possibly different for each entry (DNS lookups). > Why passing the cacheTable over ClientData? That's just because I implemented this as a module so it could be tested easily without patching. A merged version would add a slot to the NsServer structure. > Why not creating caches during server lifetime instead of only > at startup? Locking overhead. The current implementation doesn't lock the caches when for example the stats command is run, which could have the cache deleted out from under it, causing a crash. I did try a couple of ways to enable safe cache creation at runtime, including reference counting of the caches themselves. It just seemed over engineered. Do you have a situation in mind where caches should be created at runtime? > I guess answer to all of those is: this is a work in progress :-) > Well, I just wanted to put those on the table so we know what > is still left to do? > > What I miss: what is the main benefit of nscache2/cache2 over > the existing nsache/cache? The user of this code never has to do any locking. The required locking is extremely difficult, in my opinion. The API is smaller, but also more functional. It's easy to get right. Couple of extra features: built in reference counting of entries, support for per-thread caches, etc. |