DS> But the only reason that the cache needed to be linked with the reqinfo
DS> parameter was that this was the only way that lower handlers could get
DS> hold of it.
Robert> Well, technically, the handler had to have requested the cache in
Robert> the first place, so it could have save the cache pointer when it
Robert> created it
Sort of.
The lower level code typically creates a normal handler registration
structure, which creates the cache internally. The cache itself isn't
normally available explicitly, except by re-casting the 'magic' pointer
(which feels as if it ought to be private to the handler internals).
That's for a cache-based handler, of course - a manually-controlled
cache would indeed have access to the cache structure.
There's also the distinction between the cache control structure itself,
and the dataset being cached (which I seem to remember is why Wes
persuaded me to add the 'void' pointer to the cache structure and
load/free calls).
Thinking about this in abstract, it would probably be sensible for
a lower-level handler to be able to retrieve *either* of these
(independently).
Something like:
------------------------------
netsnmp_cache *
netsnmp_extract_cache_info(netsnmp_agent_request_info * reqinfo)
{
return netsnmp_agent_get_list_data(reqinfo, CACHE_NAME);
}
void *
netsnmp_extract_cache_data(netsnmp_agent_request_info * reqinfo)
{
netsnmp_cache *cache;
cache = netsnmp_agent_get_list_data(reqinfo, CACHE_NAME);
return (cache ? cache->magic : NULL );
}
------------------------------
What do you think?
DS> The cache handler *already* had a handle to the cache, using the 'myvoid'
DS> pointer. So using the reqinfo list is just going through extra work
DS> unnecessarily. An interesting definition of "optimization" :-)
Robert> The optimization wasn't in regard to getting the pointer. It was
Robert> for checking if the cache had already been dealt with. If the cache
Robert> existed in the reqinfo structure, we'd already checked the timers
Robert> and, if necessary, loaded the cache, and we shouldn't do it again.
Hmmmm.... OK, that makes a certain sort of sense....
Though I suspect that the overhead of searching the reqinfo list_data
might well be higher than comparing the timestamps regardless.
Robert> The problem is that certain scenarios can cause the cache handler
Robert> to be called twice for a single request. If the timeout is checked
Robert> each time, the cache could be cleared and reloaded, potentially
Robert> leaving someone holding a bad pointer from the previous cache.
Just to check - are we talking about a pointer to the cache control
structure, or the cached data itself?
I'd need to sit down and work through the code to be sure, but isn't
the cache control structure constant throughout the life of the module?
A pointer to the cached data (if dynamically allocated) might well become
invalid, that's true enough.
Ummm....
Maybe we need an API to retrieve the cache data from a cache control
structure? That could check the cache validity first (and maybe even
re-load the data if needed) ?
Then it'd be up to lower-level code to ask for the cached data at
the last possible minute (or face the consequences). That might
even address the delegation problem.
DS> One thing to remember is that the cache design is currently self-contained
DS> - it doesn't rely on any "external" data (such as the reqinfo parameter).
Robert> Errr... ok, well, you'll have to explain to me how the current
Robert> implementation limits it in that way. The 'cache design' is just
Robert> a data structure, and as such could be used any way the coder wants.
Yup.
It's OK - I was just concerned when you started talking about using
a data list pointer instead of the current "magic", that we might end
up needing a reqinfo structure associated with the cache itself
(rather than the cache handler).
But if you're already using caches outside this mechanism,
then it's not something I need worry about.
Robert> The 'cache handler', on the other handle,
<groan>
I wish I'd spotted that one.
<altogether - "You will, Oscar, you will">
Dave
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Net-snmp-coders mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
