On Wed, August 1, 2007 11:07 pm, Need Help wrote:
Read this comment in the code you included, and note the conditional
expression.
> } else if (block != 0 && fakeblock == 0) {
> /*
> * The caller asked for blocking, but there is an alarm due
> sooner than
> * LONG_MAX seconds from now, so use the modified timeout
> returned by
> * snmp_select_info as the timeout for select().
> */
Now note the values you reported for these variables:
> After the call to the "snmp_select_info()" routine completes, the
> following variable values are displayed:
>
> "block" is not 0
> "fakeblock" is 0
And now hopefully you can answer your own question:
> Since I am not really performing any SNMP requests, I am not sure why
> the "select()" routine is not blocking (ie: waiting for a packet) for me.
Regarding select...
> I really do
> not understand what this has to do with the "Sessions" linked list either.
select has nothing to do with any net-snmp data structures.
> Is this a NetSNMP bug which results in the "Sessions" linked list being
> corrupted somehow?
select is a system call, so it will not be modifying any net-snmp data
structures unless maybe you've passed it a bad pointer. Are there other
threads running that may be modifying these data structures?
> I do not understand what the "select()" routine really does (I can not
> find it anywhere).
select is a POSIX-standard system call. Try man select. Or google "unix
select" or something along those lines.
Pete
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
