DS> The most recent change now uses what appears to be a DS> completely separate cache structure, extracted from an DS> internal list.
Robert> The original idea was to fetch the Robert> cache from the reqinfo first thing.... Robert> ..... This was an extension of your work... Robert> I just extended the concept into the cache handler, But the only reason that the cache needed to be linked with the reqinfo parameter was that this was the only way that lower handlers could get hold of it. The cache handler *already* had a handle to the cache, using the 'myvoid' pointer. So using the reqinfo list is just going through extra work unnecessarily. An interesting definition of "optimization" :-) But you're quite right about clashing caches, of course. Thanks. I'm not sure about delegated requests - I suspect there is a potential for problems there, but I'm not sufficiently clear on how this mechanism works to be able to comment sensibly. Robert> I have a question about the 'magic' pointer. Robert> It's not clear if it is reserved for the cache handler, Robert> or the handler that registered the cache. It's for the code that actually implements the cache. The cache_handler doesn't use it at all. It's a mechanism for the cache load hook and free hook routines (and and code that needs to use the cache) to share data without needing to use global variables. So the interpretation of this pointer is totally up to these lower-level routines. Robert> In general, we should probably move away Robert> from 'magic' pointers. A data list pointer would be more useful, Well, the lower-level routines could certainly use it as such, if that was desirable. There should be no need to change the structure at all - just cast the pointer appropriately. One thing to remember is that the cache design is currently self-contained - it doesn't rely on any "external" data (such as the reqinfo parameter). This is something that I'd want to retain, since it allows the caching mechanism to be re-used elsewhere, not just in the context of SNMP requests. 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
