[AGENT++] Re: recvfrom's blocking and process grinding to a halt

[Jochen Katz]

Hi,

> Hmmm, it definately seems like it's happening from what gdb is showing
> me.  Keep in mind that I'm using my modified codebase for multiple v3MP
> objects if that changes anything (although I don't think it  should
> matter for this?).

v3MP is not envolved at this part of message receiption.

> This brings up a question.  If the msg queue is per Snmp object, how is
> the recvfrom call triggered on that thread going to know that it is
> getting data that is intended for it's Snmp object and not some other
> Snmp object in another thread that shares the same address?

Each Snmp object opens its own socket (random port if not specified). So
they cannot interfere with each other and no thread can receive data for
another thread.

> To take this to the race condition issue if the lock is per snmp object
> then it seems like it does me no good.  What if 2 threads both do a
> request to 10.0.0.1 <http://10.0.0.1> and then both select to see if
> there is data from that address at once (they can do this since they
> have different locks), each of them sees that there is data, but in
> reality there is only one datagram waiting for reading.  Now whichever
> thread gets to recvfrom first gets that datagram and the other blocks. 
> Am I missing something here or is that a potential issue?

This is no issue, as each thread / Snmp object uses it's own socket.

>     Do you get timeouts although the agent sends a reply?
> 
> 
> It's hard to know (since I'm polling the same agent hundreds of times as
> fast as I can), but I don't seem to be getting any unexpected timeouts. 
> The threads just block sometimes.