STINNER Victor <[email protected]> added the comment:
> This is in contrast with the standard C++/C behavior, where a close()
> on a socket causes an asynchronous and immediate exception/return with
> error on the functions that are using the socket at the same time (but
> in another thread).
Are you sure of that? I don't see how Python behaviour would be different to a
the same program written in C. Could you write a short example written in C to
prove that?
--
To avoid this issue (Python blocks on recv() whereas a thread closed the
socket), you should check that there is data on the socket before reading the
data. Eg. TCPServer.serve_forever() uses select.select() to avoid this issue.
Extract:
while not self.__shutdown_request:
# XXX: Consider using another file descriptor or
# connecting to the socket to wake this up instead of
# polling. Polling reduces our responsiveness to a
# shutdown request and wastes cpu at all other times.
r, w, e = select.select([self], [], [], poll_interval)
if self in r:
self._handle_request_noblock()
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue8831>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
