On Mon, 28 Jun 2004 14:21:11 +0100 Dave wrote: DS> Firstly, there appears to be an inconsistency in the DS> way that the cache is referenced
You are right, it should be consistent. I'll get that fixed today. DS> The most recent change now uses what appears to be a DS> completely separate cache structure, extracted from an DS> internal list. Actually, that change went in a while ago. The original idea was to fetch the cache from the reqinfo first thing, and return right away if it was found. This was supposed to prevent the cache from being accessed more than once for a given request. DB> If these *are* different cache structures, DS> then this seems extremely dangerous (if not plain wrong!). Well, they are supposed to be the same. This was an extension of your work. (you put the cache in the reqinfo in the first place, apparently to let handlers get it and double-check that the cache had been loaded. Which wouldn't have always worked quite like you expected, for the reasons noted in the bug report.) I just extended the concept into the cache handler, attempting to optimize and also to prevent the cache from being re-loaded mid-request. But that's probably handled by the switch on the mode. The only thing I'm not sure about is if delegated requests would hit the cache handler again with the same mode. I'll try and test that too. Speaking of delegated requests, we probably need to add some sort of locking/reference counts to the cache handler, to keep the auto-release code from unloading a cache that is being used by delegated request. Thoughts on a good way to do that are welcomed. DS> If they actually refer to the same cache structure, then DS> I don't see the point in searching for something that's DS> already available directly. Probably true. I'll most likely change the code to simply verify that if the requestinfo has a cache, it's the same as the myvoid pointer. Then the rest of the routine can just use the myvoid pointer. While we are talking about the cache handler, I have a question about the 'magic' pointer. It's not clear if it is reserved for the cache handler, or the handler that registered the cache. In general, we should probably move away from 'magic' pointers. A data list pointer would be more useful, since everyone could use it to add extra data, without changing the structure. -- 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
