On Wed, 30 Jun 2004 15:52:20 +0100 Dave wrote:
DS> Robert> Well, technically, the handler had to have requested the cache in
DS> Robert> the first place, so it could have save the cache pointer when it
DS> Robert> created it
DS>
DS> Sort of.
DS> The lower level code typically creates a normal handler registration
DS> structure, which creates the cache internally. The cache itself isn't
DS> normally available explicitly, except by re-casting the 'magic' pointer
DS> (which feels as if it ought to be private to the handler internals).
By 'magic' you mean 'myvoid', right?
DS> Thinking about this in abstract, it would probably be sensible for
DS> a lower-level handler to be able to retrieve *either* of these
DS> (independently).
DS>
DS> Something like:
DS>
DS> ------------------------------
DS> netsnmp_cache *
DS> netsnmp_extract_cache_info(netsnmp_agent_request_info * reqinfo)
DS> {
DS> return netsnmp_agent_get_list_data(reqinfo, CACHE_NAME);
DS> }
DS>
DS> void *
DS> netsnmp_extract_cache_data(netsnmp_agent_request_info * reqinfo)
DS> {
DS> netsnmp_cache *cache;
DS> cache = netsnmp_agent_get_list_data(reqinfo, CACHE_NAME);
DS> return (cache ? cache->magic : NULL );
DS> }
DS> ------------------------------
DS>
DS> What do you think?
Add in code to make the cache name something unique (see recent additions to
cache handler), and that makes sense. Though I'd name them
netsnmp_cache_reqinfo_extract_*. I think that's the naming convention we all
seemed to agree on a short while ago.
DS> DS> The cache handler *already* had a handle to the cache, using the
DS> DS> 'myvoid'
DS> DS> pointer. So using the reqinfo list is just going through extra work
DS> DS> unnecessarily. An interesting definition of "optimization" :-)
DS>
DS> Robert> The optimization wasn't in regard to getting the pointer. It was
DS> Robert> for checking if the cache had already been dealt with. If the cache
DS> Robert> existed in the reqinfo structure, we'd already checked the timers
DS> Robert> and, if necessary, loaded the cache, and we shouldn't do it again.
DS>
DS> Hmmmm.... OK, that makes a certain sort of sense....
DS> Though I suspect that the overhead of searching the reqinfo list_data
DS> might well be higher than comparing the timestamps regardless.
Probably. But the important thing is to avoid a cache reload mid-request, not
to save a compare. Sorry if that wasn't clear.
DS> Robert> The problem is that certain scenarios can cause the cache handler
DS> Robert> to be called twice for a single request. If the timeout is checked
DS> Robert> each time, the cache could be cleared and reloaded, potentially
DS> Robert> leaving someone holding a bad pointer from the previous cache.
DS>
DS> Just to check - are we talking about a pointer to the cache control
DS> structure, or the cached data itself?
The cached data.
DS> A pointer to the cached data (if dynamically allocated) might well become
DS> invalid, that's true enough.
Right. But we shouldn't let that happen mid-request.
DS> Ummm....
DS> Maybe we need an API to retrieve the cache data from a cache control
DS> structure? That could check the cache validity first (and maybe even
DS> re-load the data if needed) ?
DS> Then it'd be up to lower-level code to ask for the cached data at
DS> the last possible minute (or face the consequences). That might
DS> even address the delegation problem.
No. I *really* *really* *really* think we need to ensure that the cache is
consistent for the duration of a single request processes. Asking the handlers
to deal with a cache that changes underneath them is just to high a burden.
Here's an example. What happens if, just prior to the commit phase of a set to
a row status object, the cache is freed? If, as you propose, the users' handler
needs to deal with this, they also have to deal with the fact that their
decisions on whether or not to allow this set, which was made in RESERVE 1 or
2, needs to be re-evaluated. The only way they could easily deal with this
would be to bail with GENERR.
--
Robert Story; NET-SNMP Junkie <http://www.net-snmp.org/>
<irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders>
You are lost in a twisty maze of little standards, all different.
-------------------------------------------------------
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
