This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ryan003
Recipients benjamin.peterson, neologix, pitrou, python-dev, ryan003, victorpoluceno, vstinner
Date 2011-05-24.22:58:14
SpamBayes Score 4.01107e-09
Marked as misclassified No
Message-id <53866993-793A-45AD-88B4-F8720DEFBD39@gmail.com>
In-reply-to <1306259072.9.0.765413481894.issue5715@psf.upfronthosting.co.za>
Content
On May 24, 2011, at 12:44 PM, Charles-François Natali wrote:

> I don't know how I could miss this: closing the server socket is perfectly fine in TCP, since a new one is returned by accept(). But in UDP, it's definitely wrong, since it's used by the handler.
> I don't know however how I missed this, since I remember having run test_socketserver...

It's been a long time since the issue submitted, anyway, I was cursed to look at only TCP too :-)

I agree that ForkingUDPServer should be supported in SocketServer.py.
(Although users should take care of socket locking for concurrent accesses)

How about using BaseServer(TCPServer).server_close() instead of self.socket.close() in the patch?

As UDPServer has no server_close() method overridden, unlike ForkingTCPServer, ForkingUDPServer seems to have no actual "server" in design.
So, I think we could say that 
- closing TCP listen socket in child process = "server_close()" in child process
- nothing to do on UDP socket in child process = "server_close() but nothing will be done in the method" (b/c BaseServer.server_close() does nothing)

What do you think?

-----
Donghyun Kim
http://www.uryan.net
Files
File name Uploaded
unnamed ryan003, 2011-05-24.22:58:13
History
Date User Action Args
2011-05-24 22:58:15ryan003setrecipients: + ryan003, pitrou, vstinner, benjamin.peterson, victorpoluceno, neologix, python-dev
2011-05-24 22:58:14ryan003linkissue5715 messages
2011-05-24 22:58:14ryan003create