[issue38188] Incorrect Argument Order for Calls to _winapi.DuplicateHandle() in multiprocessing.reduction.DupHandle

Change by Eryk Sun : -- components: +Library (Lib) stage: -> needs patch type: -> behavior versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7 ___ Python tracker ___

[issue38188] Incorrect Argument Order for Calls to _winapi.DuplicateHandle() in multiprocessing.reduction.DupHandle

Eryk Sun added the comment: Let's make test_fd_transfer_windows a bit less hangy by polling for up to 60 seconds instead of simply trying to recv() and by terminating before trying to join(). @unittest.skipUnless(HAS_REDUCTION, "test needs multiprocessing.reduction")

[issue38188] Incorrect Argument Order for Calls to _winapi.DuplicateHandle() in multiprocessing.reduction.DupHandle

Eryk Sun added the comment: As far as I can tell, reduction.send_handle isn't used internally in the Windows implementation, and it's also not a documented API function. However, it is tested on Windows in test_fd_transfer in Lib/test/_test_multiprocessing.py. As it turns out, the bug that

[issue38188] Incorrect Argument Order for Calls to _winapi.DuplicateHandle() in multiprocessing.reduction.DupHandle

Change by Ammar Askar : -- nosy: +eryksun ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38188] Incorrect Argument Order for Calls to _winapi.DuplicateHandle() in multiprocessing.reduction.DupHandle

New submission from Cameron Kennedy : The DuplicateHandle function is utilized by the DupHandle object to duplicate handles for the purpose of sending and receiving between processes on Windows systems. At least on Python 3.7.3, this function is invoked with an incorrect argument order. In