[issue8831] recv and recvfrom on UDP socket do not return/throw exception after a close()
Charles-Francois Natali neolo...@free.fr added the comment: 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? I also found this surprising, so I wroke a quick C program to test this (see attached C code), and as expected, calling close() from the main thread _doesn't_ result in recv() returning (and the socket still shows up in a netstat -A inet -a). Furthermore, closing a socket still in use by another thread is probably quite questionable, and close(2) man page makes it clear: It is probably unwise to close file descriptors while they may be in use by system calls in other threads in the same process. Since a file descriptor may be re-used, there are some obscure race conditions that may cause unintended side effects. So I'd suggest to close this issue. -- nosy: +neologix Added file: http://bugs.python.org/file19012/test_socket.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8831] recv and recvfrom on UDP socket do not return/throw exception after a close()
Martin v. Löwis mar...@v.loewis.de added the comment: Closing, as suggested by neologix -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8831] recv and recvfrom on UDP socket do not return/throw exception after a close()
New submission from Alessandro Roat alexr...@gmail.com: A thread blocked on a recv or a recvfrom method on a UDP socket (waiting for a datagram) can not be unlocked calling a .close() from a different thread. 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). Thus, it is impossible to unlock a waiting recv/recvfrom calling a close() or a shutdown() if no more datagrams are coming. -- components: IO messages: 106596 nosy: Alessandro.Roat priority: normal severity: normal status: open title: recv and recvfrom on UDP socket do not return/throw exception after a close() type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8831] recv and recvfrom on UDP socket do not return/throw exception after a close()
Changes by Giampaolo Rodola' g.rod...@gmail.com: -- nosy: +giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8831] recv and recvfrom on UDP socket do not return/throw exception after a close()
Martin v. Löwis mar...@v.loewis.de added the comment: Can you provide a patch? -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8831] recv and recvfrom on UDP socket do not return/throw exception after a close()
STINNER Victor victor.stin...@haypocalc.com added the comment: And maybe also a short example? :) -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8831] recv and recvfrom on UDP socket do not return/throw exception after a close()
Alessandro Roat alexr...@gmail.com added the comment: This is an example, test it with netcat (nc -u localhost ) on linux (ubuntu 9.10). Lauch it with python scriptname, a prompt will appear. Type start to launch the server, test the server sending UDP packets with netcat, the lenght of packet will be correctly printed. However, when you'll type stop the close will be invoked but the receiving thread wont stop and the join in the stop() wont never return and you will need to kill the python interpreter. import socket import threading import sys import select class UDPServer: def __init__(self): self.s=None self.t=None def start(self,port=): if not self.s: self.s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM) self.s.bind((,port)) self.t=threading.Thread(target=self.run) self.t.start() def stop(self): if self.s: self.s.close() self.t.join() self.t=None def run(self): while True: try: data,addr=self.s.recvfrom(1024) print recv done if len(data)=0: raise self.onPacket(addr,data) except: break #chiusura socket print server is no more running self.s=None def onPacket(self,addr,data): print len(data) us=UDPServer() while True: sys.stdout.write(UDP server ) cmd=sys.stdin.readline() if cmd==start\n: print starting server... us.start() print done elif cmd==stop\n: print stopping server... us.stop() print done elif cmd==quit\n: print Quitting ... us.stop() break; print bye bye -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8831] recv and recvfrom on UDP socket do not return/throw exception after a close()
STINNER Victor victor.stin...@haypocalc.com 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 rep...@bugs.python.org http://bugs.python.org/issue8831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
