On Tue, 29 Jun 2004 10:29:54 +0100 Dave wrote: DS> Robert> The original idea was to fetch the DS> Robert> cache from the reqinfo first thing.... DS> Robert> ..... This was an extension of your work... DS> Robert> I just extended the concept into the cache handler, DS> 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.
Well, technically, the handler had to have requested the cache in the first place, so it could have save the cache pointer when it created it (which is what the array-user code does for it's structure). But other, intermediate, handlers would be left out in the cold. Then again, they probably shouldn't be mucking about with a data structure that isn't theirs. 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" :-) The optimization wasn't in regard to getting the pointer. It was for checking if the cache had already been dealt with. If the cache existed in the reqinfo structure, we'd already checked the timers and, if necessary, loaded the cache, and we shouldn't do it again. The problem is that certain scenarios can cause the cache handler to be called twice for a single request. If the timeout is checked each time, the cache could be cleared and reloaded, potentially leaving someone holding a bad pointer from the previous cache. So, is preventing a core dump a little better justification than and 'optimization'? :-) DS> I'm not sure about delegated requests - I suspect there is a potential DS> for problems there, but I'm not sufficiently clear on how this mechanism DS> works to be able to comment sensibly. The problem is that a delegated request doesn't finish in a single snmp_read call. It will fall out of snmp_read, which means that alarms have a chance to run. If the timing is right, a cache could be unloaded while a delegated request still has a pointer. When the delegated requests call back is called and it tried to use the pointer... DS> Robert> I have a question about the 'magic' pointer. DS> Robert> It's not clear if it is reserved for the cache handler, DS> Robert> or the handler that registered the cache. DS> DS> It's for the code that actually implements the cache. DS> The cache_handler doesn't use it at all. I knew it didn't currently use it, but it's conceivable that it would. I'll update the header to indicate it's for end-user use. 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). DS> This is something that I'd want to retain, since it allows the caching DS> mechanism to be re-used elsewhere, not just in the context of SNMP DS> requests. Errr... ok, well, you'll have to explain to me how the current implementation limits it in that way. The 'cache design' is just a data structure, and as such could be used any way the coder wants. The 'cache handler', on the other handle, is pretty obviously tied to a request. Which isn't to say that the cache cant be used outside of the context of a request. In fact, the latest ifTable implementation uses the new auto-reload feature to keep the cache up to date even in the absence of any requests. -- 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
