On Thu, 01 Jul 2004 11:34:28 +0100 Dave wrote:
DS> DS> Thinking about this in abstract, it would probably be sensible for
DS> DS> a lower-level handler to be able to retrieve *either* of these
DS> DS> netsnmp_extract_cache_info(netsnmp_agent_request_info * reqinfo)
DS> DS> netsnmp_extract_cache_data(netsnmp_agent_request_info * reqinfo)
DS> DS> What do you think?
DS>
DS> Robert> Though I'd name them netsnmp_cache_reqinfo_extract_*.
DS>
DS> I'm not sure I'd bother with the "_reqinfo" there, though.
DS> As a MIB implementer, I just want to get hold of the cache
DS> (control structure or cached data as appropriate).
DS> I don't care *where* it's obtained from.
DS> So netsnmp_cache_extract_{info,data} should be sufficient.
You have to care where it comes from - that's one of the parameters. If I see
'netsnmp_cache_extract', I think 'ok, we are extracting something from the
cache'.
DS> But that's not a particularly vital point.
No, but we're running out of vital ones, and I have to have something to argue
about! ;-)
DS> Robert> But we shouldn't let [the cached data become invalid] mid-request.
DS> [...]
DS> Actually, having put it that way, I think you're probably right.
DS>
DS> So the cache handler probably needs to set an internal lock when it's
DS> first called (i.e. at the beginning of the first processing pass),
DS> and release it again at the end of the last processing pass [...]
DS>
DS> Is that the sort of thing you had in mind?
Basically, yes, but I was thinking more along the lines of a reference count
(think tables sharing a cache). I tend to think of threads when I hear locking.
DS> (be that MODE_GET or MODE_COMMIT or whatever).
So long as it runs after all varbinds in a request have been processed, that's
fine. I thought something along the lines of a cache_release helper object,
which would basically be a dummy item added to the reqinfo data list, with a
free routine that released the resource.
DS> What should the "cache_free" routine do if the cache is locked
DS> when it's called? Block until it's released again? Or schedule
DS> another free at a later date? Or something else?
It can't block, since the agent is single threaded. I'd say it should skip that
cache and deal with any that weren't locked, and then go about it's merry way.
Another option is to do away with the periodic clean-up, and have each cache
regeister it's own alarm to release after the cache has expired. One less
global list to worry about, if we ever go multi-threaded.
DS> What about breaking stale locks?
Good question. Initially I'd say not worry about them, as a stale lock would
imply a serious bug somewhere. But a watchdog alarm to log a message probably
wouldn't hurt.
--
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
