SocketServer.ThreadingUnixStreamServer leaks file descriptors when a 
request handler throws an exception.

Please provide a small test code that manifests the problem. It is
always the best way to get quick response.

I was toying with adding Unix Socket support for one of our internal tools and I thought I ran into a leak in my own code. Searched the bug tracker and found this.

I tried to reproduce, but wasn't able to. Though, if you look at the ThreadingMixIn class, you'll see this:

self.handle_error(request, client_address)
self.close_request(request)

An exception in handle_error, most likely from a subclass, would cause close_request to never fire. Though, the socket.accept'd channel would probably be shut down implicitly when leaving _handle_request_nonblock.

This will go nowhere unless a patch is provided that contains code, doc and unit test changes.

I'll see if I can get it to reproduce and put a patch together.

I entirely forgot I had signed up to look, my apologies. 

I'm going through this w/ what's lying on Mercurial's tip, I can't reproduce it at all. I can raise exceptions of various flavors from within the handle method of a StreamRequestHandler and there are no leaking file descriptors.  

The only thing worthy of discusion, IMO, is the fact that raising an exception in a handle_error method of a subclass of BaseServer *does* cause the the self.shutdown_request to not run.  

Unless I'm mistaken, that does then leave the cleanup of that open socket to GC (but, at that point, anyone overriding handle_error method should know that). Does it make sense to run shutdown_request, even if handle_error throws an Exception?  

If anyone thinks that's worthwhile, I can do that.