Well, that explains asynchronous, but why single session? Here is my understanding: The Traditional API manages a global list for all sessions, and session operations are not thread-safe because the global session list does not have locks. The Single API makes operations thread-safe by using a thread-local session list via an opaque session pointer (a session list with a single session) instead of using a global session list. Correct me if I am wrong on this one (see link below) : http://www.net-snmp.org/docs/README.thread.html
If you really use threads, why not a thread for each session, and then the pointer will be a thread local variable? Yes, this is what I am doing with the Single API. I had difficulty with sessions "dieing" when using the Traditional API with multiple threads. Even though each thread had its own session, all threads shared the global session list. According to README.thread, the global session list was the problem, and the Single API was the solution. So far, I have used the Single API with synchronous requests successfully in a multi-threaded program. Yes, the asynchronous tutorial was very helpful to get me started. README.thread helped me translate the async tutorial to the Single API. The main thing the async tutorial did not demonstrate was how to do queries with multiple sends (walk/table requests). I'll try to post some sample code for async walks next week after I finish working things out. Assuming the code looks good, can I add it to the wiki? Thank you sanity checking my thought to put the opaque session pointer in the callback data struct. On Wed, Jul 21, 2010 at 16:30, Niels Baggesen <[email protected]> wrote: > Den 21-07-2010 21:53, Brendan Tauras skrev: >> >> Now you're probably thinking why do asynchronous Single API requests. >> I have been tasked to write a snmp monitoring program. It must >> request different OIDs at different time intervals, and one request >> cannot hold up another (e.g. walks can take a while). I am using >> threads for timing different intervals and asynchronous methods to >> keep multiple requests in a single interval from delaying each other. > > Well, that explains asynchronous, but why single session? > > If you really use threads, why not a thread for each session, and then the > pointer will be a thread local variable? > > Otherwise, have you seen the async tutorial > http://www.net-snmp.org/wiki/index.php/TUT:Simple_Async_Application > > Anyway, I don't see the problem of saving the opaque pointer inside the > struct that the callback brings back to you with its opaque pointer. > > /Niels > > -- > Niels Baggesen - @home - Århus - Denmark - [email protected] > The purpose of computing is insight, not numbers --- R W Hamming > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
