[AGENT++] Asynchronous interface in SNMP++

[Jochen Katz]

Hi,

> - Probably, as the console example suggests, SNMP++ can only listen on a
> single port for traps (CNotifyEventQueue::set_listen_port(trap_port)). Thus,
> it is impossible to listen on multiple ports (e.g., 162, 500 and 1200)?

this is true, but it's little work to remove the static functions and 
vars from CNotifyEventQueue.

> - Any thread can be used to execute callbacks, including the synchronous
> ones, which wait for responses  (the callbacks get processed in
> EventListHolder::SNMPProcessPendingEvents(), which in turn calls
> m_eventList.HandleEvents()). This may be a bit surprising for a programmer.

Indeed, this could be a surprise...

> I do not have an example of a program in which this behavior would cause
> bugs but I would expect that synchronous operations will be "atomic" and no
> other code will get executed in the meantime. Additionally, since the
> callbacks could in turn call subsequent methods on an Snmp object, it (and
> the subobjects it uses) must be reentrant (it must be safe for the same
> thread to enter a function multiple times). Fortunately, it seems to be ok.

But it is not allowed to issue sync requests from a callback.

> - There is also a puzzle - how exactly the following function is intended to
> work?

As you wrote, the code has a long history. The HP code had global event 
lists. These were changed to have an event list for each Snmp object 
(EventListHolder). Actually I don't like the event handling code, 
because it's hard to understand and even if you think you know all 
dependencies there's still one you missed.

> It looks that the check in while() is just some kind of optimization and
> that msgEltPtr->GetEvents()->HandleEvents() must be MT-safe in itself. Could
> it happen that it will be CNotifyEventQueue::HandleEvents()? This one does
> not seem to be locked. Or maybe, it has not been tested in a truly MT
> environment?

Yes, CEventList::HandleEvents() will call 
CNotifyEventQueue::HandleEvents(), but this method is locked using the 
REENTRANT macro.

> Summarizing: I think that the synchronous threads should not execute
> callbacks. Callbacks should be executed by threads that explicitly enter
> event processing loop, e.g. calling something like
> snmp.eventListHolder->SNMPProcessEvents().

Of course this would be better. It would require an additional queue 
where responses are stored that just wait for the call of the callback.

Regards,
   Jochen