Okko Willeboordse added the comment:
I bumped into this issue at one of my customers that use Python to control a
machine through Beckhoff EtherCAT. The Python code communicates with the
Beckhoff EtherCAT program using TCP/IP.
They use non blocking sockets like so;
s = select.select([self._socket], [], [], timeout)[0]
if not s:
raise NoData
self._socket.recv(length)
They also found that the recv occasionally raises a 10035.
I changed the code in to;
s = select.select([self._socket], [], [], timeout)[0]
if not s:
raise NoData
try:
buffer_ = self._socket.recv(length)
except socket.error as inst:
if (gaius.utils.Platform.WINDOWS and 10035 == inst.args[0]) or \
(gaius.utils.Platform.LINUX and 11 == inst.args[0]):
raise NoData
So this issue applies also to sockets without timeout, albeit it can be worked
around easily.
Also note that this also applies to Linux as the man page of select states in
the BUG section;
Under Linux, select() may report a socket file descriptor as "ready for
reading", while nevertheless a subsequent read blocks. This could for
example happen when data has arrived but upon examination has wrong
checksum and is discarded. There may be other circumstances in which a
file descriptor is spuriously reported as ready. Thus it may be safer
to use O_NONBLOCK on sockets that should not block.
Note that Linux select is not Posix compliant as Posix states;
A descriptor shall be considered ready for reading when a call to an input
function with O_NONBLOCK clear would not block, whether or not the function
would transfer data successfully.
See https://lkml.org/lkml/2011/6/18/76
MSDN select says;
For other sockets, readability means that queued data is available for reading
such that a call to recv, WSARecv, WSARecvFrom, or recvfrom is guaranteed not
to block.
http://support.microsoft.com/kb/177346 says (for Windows 95);
The Winsock select() API might fail to block on a nonblocking socket and return
WSAEWOULDBLOCK as an error code when either send() or recv() is subsequently
called. For example, select() may return indicating there is data to read, yet
a call to recv() returns with the error code WSAEWOULDBLOCK, indicating there
is no data immediately available. Windows NT 4.0 does not exhibit this behavior.
Finally I have 2 questions;
Is this select behavior on Windows 'normal'? Noting that it is not documented.
or does it behaves this way due to crippled NIC's or drivers (VMWare)?
Can this behavior be reproduced? I need this for automatic testing. Now these
exceptional paths cannot be tested.
--
nosy: +Okko.Willeboordse
___
Python tracker
<http://bugs.python.org/issue9090>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
