On Mon, 11 Oct 2004 21:30:16 +0200 Hermann wrote: HL> I have written a short paper[1] that deals with multithreaded OID HL> handling. It discusses a few starting points. HL> I am looking forward to receiving your feedback and your help for HL> further steps, the implementation. HL> HL> [1] http://caesar.ssw.uni-linz.ac.at/net-snmp-mt/mt-paper.pdf
A few points. 1) A much more detailed analysis of all APIs in netsnmp is needed. The agent uses lots of functions from the base snmplib. There are globals that will need multi-threaded protection (the data-store stuff comes to mind). 2) netsnmp_delegated_list is for requests that an individual handler has delegated in some way to another process. Those requests will be handled by those handlers, and no attempts at concurrent processing should be made. 3) handle_var_requests handles individual requests received in a PDU. I don't think that you can split these up for concurrent processing this high in the code flow. Packets with multiple requests are often for table rows, in which case some or all the requests are related and should be processed together. 4) I think the idea that multi-threading can be added in the agent library, and the agent will suddenly be ready for high-performance operation is much to simplistic. (And if high-performance is really the goal, you should probably start with profiling the code to look for current bottlenecks that can be eliminated by optimizing the code in question.) If you want to help start moving the agent towards a multi-threaded implementation, I think you should do so in small steps. The first step I would recommend would be to simply separate packet reception from packet processing. On thread would simply receive packets and put them in a queue for the second thread to process them. A fairly simple algorithm could check for duplicate packets (retries) received while the agent was busy processing a previous packet. Once that works, I would look into moving packet decoding into the reception thread. I don't think it would warrant it's own thread, as I expect that the decoding of packets to be fairly quick. Those first two steps should be fairly easy to accomplish, with minimal concurrency concerns. Only the queue of received packets/PDUs is shared between the two threads. The next step would be to move the initial grunt work of looking up the appropriate handler for each request into the packet reception thread as well. This gets into more concurrency issues, as now the registration tables are being accessed by two threads. As for actual multithreaded handling of individual objects, I suggest that you start by coming up with an injectable handler that would handle moving an individual module into its own thread. That was individual modules that have been reviewed and determined to be safe to move into a separate thread could be moved with a simple conf file change. -- 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 is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
