> So then the return value is then pretty useless if I wanted to make some > sense of what is causing the select to return.
It basically tells you whether there's anything waiting to be read or not. Treat it as a true/false value, rather than a meaningful integer. > So right now if we get a non-zero return (or between 1 and n) then we try > to process the information. Yes. > This effectively calls agent_check_and_process everytime. > And only when it's the incoming Get packet do we go and do the > dirty work to process it. Close. Only when the incoming packet is on one of the SNMP sockets, do we go and do the dirty work to process it. At this point, we've no idea *what* the incoming packet is - just which socket it was received on. > But I'm wondering if it might be useful to > figure out in my code whether it's really the incoming Get request before > calling agent_check_and_process (so as to not cause as much undo "churn"). If the incoming request is on a different (non-SNMP) socket, then 'agent_check_and_process' will recognise that none of the SNMP sockets have been tickled, and will return almost immediately. The first thimg that 'snmp_read' does for each of the internal sessions is check the select fd_set. The rest of the SNMP processing is dependent on there being something to read. > Or maybe it's correct for agent_check_and_process to figure this out and I > shouldn't fix what's not broke. I'd say it's not really broken, and isn't worth fixing. Dave ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
