Hold on - Robert suggested just *two* threads - one to receive the requests and *one* to process them. A single worker thread - not multiple threads. That means there's a single point where concurrency needs to be handled - the queueing/dequeueing of requests on this "to-be-processed" list.
yeah, your are right, one step after another ;) So this should be fairly easily to implement, the queue is the only concurrency point, as you said.
As soon as you move to multiple worker threads, you start having to think about interactions between different handlers and concurrency between them. That's obviously a sensible goal in the long run, but I'd suggest you tackle this one step at a time.
This is going to be the great challange.
So the concurrency handling could be dealt with by the 'handle_snmp_packet' routine, rather than having to delve into the innards of the library. That feels a much safer approach than trying to make the whole library inherently multi-threaded.
I agree with you, to get the internal of the library ready for multi-threaded is a hard job, so it's better to leave decoding of the packet serially.
So then I will try my first steps towards a multithreaded approach with handle_snmp_packet. As the following functions only use the netsnmp_agent_session *asp pointer the shared variables (netsnmp_handler, ..) are easier to track.
I will inform you, when the first step (queue, one receiving, one worker thread) is ready.
Hermann
------------------------------------------------------- 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
