homepage

In multiprocessing.connection on Windows, socket handles are indirectly duplicated using DuplicateHandle() instead the WSADuplicateSocket(). According to Microsoft's documentation this is not supported.
This is easily avoided by using socket.detach() instead of duplicating the handle.

What is the bug that this fixes? Can you provide a test case?

> What is the bug that this fixes? Can you provide a test case?
The bug is using an API in a way that the documentation says is wrong/unreliable. There does not seem to be a classification for that.
I have never seen a problem caused by using DuplicateHandle() so I cannot provide a test case. Note that socket.dup() used to be implemented using DuplicateHandle(), but that was changed to WSADuplicateSocket(). See Issue 9753.

Actually Issue 9753 was causing failures in test_socket.BasicTCPTest and test_socket.BasicTCPTest2 on at least one Windows XP machine.

Is there a reason the patch changes close() to win32.CloseHandle()?

> Is there a reason the patch changes close() to win32.CloseHandle()?
This is a Windows only code path so close() is just an alias for win32.CloseHandle(). It allow removal of the lines 
 # Late import because of circular import
 from multiprocessing.forking import duplicate, close

New changeset f8a92fd084c2 by Antoine Pitrou in branch 'default':
Issue #14522: Avoid duplicating socket handles in multiprocessing.connection.
http://hg.python.org/cpython/rev/f8a92fd084c2 

Patch committed, thank you!

multiprocessing.reduction still appears to use DuplicateHandle to copy sockets.
I propose adding a pair of custom functions to _multiprocessing, that "pickles" and "unpickles" handles. It can detect socket handles as being different from e.g. pipe handles by using WSADuplicateSocket and return a bytes object, similar to what is already done in socketmodule (see issue 14310)
On non-windows, this would be a no-op.
_multiprocessing already linkes with winsock, whereas the subprocess is part of python core which doesn't.

> multiprocessing.reduction still appears to use DuplicateHandle to copy sockets.
It's probably a separate issue, then. This one is about multiprocessing.connection :)

possibly, multiprocessing.Connection uses handles, which can be socket handles on windows, and that code also uses DuplicateHandle. I think a generic solution must be found for multiprocessing, so I'll create a separate issue.

> I think a generic solution must be found for multiprocessing, so I'll 
> create a separate issue.
I have submitted a patch for Issue 4892 which makes connection and socket objects picklable. It uses socket.share() and socket.fromshare() on Windows.