New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
multiprocessing/win32: WindowsError: [Error 0] Success on Pipe() #53345
Comments
I am using Python 2.6.5/win32, and working with multiprocessing module, doing that with Python interpreter embedded using Cython (if that may be related to the problem). While creating a subprocess and a Pipe to communicate with it, I've got the following traceback (particulaly on the line "parent_conn, child_conn = Pipe()"): Traceback (most recent call last):
File "test_fork.py", line 24, in init test_fork (test_fork.c:810)
vasia.main()
File "Z:\multiprocessing_cython_w32\vasia.py", line 15, in main
parent_conn, child_conn = Pipe()
File "Z:\python-win32\2.6.5\Lib\multiprocessing\__init__.py", line 106, in Pipe
return Pipe(duplex)
File "Z:\python-win32\2.6.5\Lib\multiprocessing\connection.py", line 202, in Pipe
h2, win32.PIPE_READMODE_MESSAGE, None, None
WindowsError: [Error 0] Success Lines 202-204 in multiprocessing/connection.py contain the following: win32.SetNamedPipeHandleState(
h2, win32.PIPE_READMODE_MESSAGE, None, None
) It seems to me that for some reason SetNamedPipeHandleState might be returning 0 even while it didn't fail actually; a quick check confirmed that it could be fixed by changing the above lines to the following:
(win32) |
Sorry for formatting above, a copypaste issue. The lines 202-204: The change that fixes the problem (at least for me): |
Can you provide a test case for this? |
Sorry for being a little bit slow to respond... |
I'm not sure how we take this forward as the code was changed via bpo-11750, can somebody please advise. |
Though the code may have changed a bit in the meantime (bpo-11750 in particular), the calls to _winapi.SetNamedPipeHandleState in Lib/multiprocessing/connection.py are still present and largely the same as when this issue was first opened. The implementation of _winapi.SetNamedPipeHandleState still has the potential to raise a WindowsError with its message (i.e. e.args[0]) set to whatever the Windows GetLastError() function returns. My reading of the MSDN docs and the code in Modules/_winapi.c is as follows:
Possibly the MSDN docs are incomplete on this specific matter and/or there could be other environmental factors on the system(s) where this issue has been observed not to mention other wrinkles from the OP's reported use of Cython to embed the Python interpreter to trigger the issue. A google search for other situations triggering this same behavior did turn up mentions of encountering it inside the Wine environment running on Ubuntu -- debugging Wine's re-implementation of Windows APIs is certainly out-of-scope here. It is possible that this issue is caused by environmental issues and may not be possible to provoke in a supported standard Windows system environment. Without a test case or some other way to provoke or reproduce the issue, there is little capability to pursue this further. The OP kindly followed up several years ago to say that he could not find a way to reproduce the issue reliably. Given that, the above review of the code, and the search results from looking for other instances of this sort of issue, I am going ahead with closing this issue. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: