| msg106596 - (view) |
Author: Alessandro Roat (Alessandro.Roat) |
Date: 2010-05-27 08:43 |
| 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. |
|
|
| msg106597 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2010-05-27 09:19 |
| Can you provide a patch? |
|
|
| msg106598 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2010-05-27 09:34 |
| And maybe also a short example? :) |
|
|
| msg106606 - (view) |
Author: Alessandro Roat (Alessandro.Roat) |
Date: 2010-05-27 10:52 |
| This is an example, test it with netcat (nc -u localhost 8888) on linux (ubuntu 9.10). Lauch it with python , 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=8888): 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(8888) 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" |
|
|
| msg106607 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2010-05-27 11:35 |
| > 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() |
|
|
| msg117379 - (view) |
Author: Charles-François Natali (neologix) * |
Date: 2010-09-25 16:36 |
| > 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. |
|
|
| msg117393 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2010-09-25 21:27 |
| Closing, as suggested by neologix |
|
|