Hi all,
Wondering if anyone else has had a problem similar to this. I don't
know if it's a driver problem or an app problem, but I suspect
driver at this point.
My program is running, accepting UDP packets for a very long time
(tens of thousands). After enough time, it appears that recvfrom
returns EINTR. Now I understand that this just means "interrupted
by a signal", so the code immediately calls recvfrom again.
However, the stack doesn't give me the packet. Instead, it appears
to be queued, and I reenter a blocking state. Once this has
happened, that UDP socket will never again receive--ever new packet
gives me an EINTR, and the packet is queued. I can "netstat -a" and
see the Recv-Q building up on my socket, even though I'm continually
in a loop calling recvfrom.
My questions: anyone else seen behaviour like this? Is there any
other diagnosis I can perform? Even though I suspect it really
isn't EINTR, is there anyway I can verify this, or determine what
signal may have caused it if it is a real problem? Lastly, are
there any updated ethernet drivers available?
--Andy Gryc
------------------------ Yahoo! Groups Sponsor --------------------~-->
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/CFFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|