DS> 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).
Robert> By 'magic' you mean 'myvoid', right?
Err... yes, probably.
<tap, tap, tap>
Yup - we're talking about the cache control structure here, so you're
right - it uses 'myvoid'.
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> netsnmp_cache *
DS> netsnmp_extract_cache_info(netsnmp_agent_request_info * reqinfo)
DS> void *
DS> netsnmp_extract_cache_data(netsnmp_agent_request_info * reqinfo)
DS> What do you think?
Robert> Add in code to make the cache name something unique
Robert> (see recent additions to cache handler), and that makes sense.
Yup - good point.
Robert> Though I'd name them netsnmp_cache_reqinfo_extract_*.
Robert> I think that's the naming convention we all
Robert> seemed to agree on a short while ago.
We all agreed on something? Sounds unlikely :-)
I'm not sure I'd bother with the "_reqinfo" there, though.
As a MIB implementer, I just want to get hold of the cache
(control structure or cached data as appropriate).
I don't care *where* it's obtained from.
So
netsnmp_cache_extract_{info,data}
should be sufficient.
But that's not a particularly vital point.
Robert> But the important thing is to avoid a cache reload mid-request,
Robert> not to save a compare. Sorry if that wasn't clear.
Robert> But we shouldn't let [the cached data become invalid] mid-request.
Robert> I *really* *really* *really* think we need to ensure that the
Robert> cache is consistent for the duration of a single request processes.
Robert> Asking the handlers to deal with a cache that changes underneath
Robert> them is just to high a burden.
Hmmmm... well if you feel that strongly about it....
Actually, having put it that way, I think you're probably right.
So the cache handler probably needs to set an internal lock when it's
first called (i.e. at the beginning of the first processing pass),
and release it again at the end of the last processing pass
(be that MODE_GET or MODE_COMMIT or whatever).
Is that the sort of thing you had in mind?
What should the "cache_free" routine do if the cache is locked
when it's called? Block until it's released again? Or schedule
another free at a later date? Or something else?
What about breaking stale locks?
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
