Changing Timeouts (Re: memory leaks in snmp++)

[Jochen Katz]

Hi Henning,

> If there are currently no events in the list, "GetNextTimeout" returns
> "Infinite" which makes "GetDelta" return the "MAX_ALARM" value. This value
> is currently defined to "1000000000L", over 37 years, which really is
> infinite in this context.

until here it is fine, as if nothing is to be done we can sleep/wait 
forever...

> What happens, if the application launces a new GET
> request within these 37 years, which receives no response and should be
> timed out?

..but yes, from this point it behaves badly. The original snmp++ did 
not support multiple threads, so this could not happen. But now we have 
to change it.

When sending out async requests, while SNMPMainLoop() is 
sleeping/waiting in select(), the callback is not called until the 
select() returns, so even a 1 second timeout could be too long.

> 2.) Use the "max_block_seconds" parameter of
> "EventListHolder::SNMPProcessEvents()". This can only be done effectively by
> adding this parameter to "EventListHolder::SNMPMainLoop()" which is then
> passed to "EventListHolder::SNMPProcessEvents()". This would look like this:
> 
> void EventListHolder::SNMPMainLoop(const int max_block_seconds /* =  0 */ )

Are there any objections against changing this to milliseconds?

void EventListHolder::SNMPMainLoop(const int max_block_milliseconds = 1000);
int EventListHolder::SNMPProcessEvents(const int max_block_milliseconds 
= 0);

> The question remains if using such an "infinite" value on "select()" is such
> a good idea in the first place. I think "select()" should return every now
> and then so that any other events may be checked on. Finding a good value
> for a time-out here is really a question of performance. Alternatively,
> time-out processing could be done in a seperate thread...

With the params changed to milliseconds everybody can use his preferred 
value.

Regards,
   Jochen