Re: [Dproxy-devel] dproxy 1.x

[Benjamin C. <li...@se...>]

On Thu, 10 Feb 2000, Andreas Hofmeister wrote:
<SNIP>
> combination of refcount and LRU time like this:
> 
> - every time an entry is referenced, we incremt the refcount.
> - every time the LRU time is < now - cache_expiration_time  , we decrement
> the refcount and set the LRU to now.
> - if the refcount drops to 0, rmove the entry.

I like it!

> --- Job #1 --
...disk cache stuff

> --- Job #2 ---
> We need a LL implementation. As we maybe want to re-use  it (refresh list
> ...), it should be in a separate module, i would suggest an api like this:

I'll do this. I enjoy lls. 

> typedef struct {...} list_t;
> tyepdef struct { list_t * list , ll_entry_t *pNext , cache_data_t * data }
> ll_entry;

The cache_data_t will could cause problems if the implementation of the
refresh list requires extra fields (ie a delay to rechech the host later
if it's down). Guess we can cross that hurdle when we get there though.

> We need to remove entries from the middle of the list, so we maybe should
> implement this as a double linked list. Some of the functions are trivial and
> could be implemented as macros.  (or inlines, but some compilers  can not use
> inline)

Macro's are the safer option, most compilers like them.
I think we can get away with a single linked list.
After all we have to go from the front to the end on our search anyway -
why not keep a pointer to the previous entry as we search.

I take it the ll will only be searched by the initial instance of dproxy.
Hence avoiding locks/memory sharing. If not let me know.

Cheers,
--

* Benjamin Close
* Be...@se...
* Web Page: http://users.senet.com.au/~benjsc