homepage

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-win322円.6.5\Lib\multiprocessing\__init__.py", line 106, in Pipe
 return Pipe(duplex)
 File "Z:\python-win322円.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:
 try: 
 win32.SetNamedPipeHandleState( 
 h2, win32.PIPE_READMODE_MESSAGE, None, None 
 ) 
 except WindowsError, e: 
(win32) 
 if e.args[0] != 0: # 0 is error code for SUCCESS 
 raise

Sorry for formatting above, a copypaste issue.
The lines 202-204:
 win32.SetNamedPipeHandleState(
 h2, win32.PIPE_READMODE_MESSAGE, None, None
 )
The change that fixes the problem (at least for me):
 try:
 win32.SetNamedPipeHandleState(
 h2, win32.PIPE_READMODE_MESSAGE, None, None
 )
 except WindowsError, e:
 if e.args[0] != 0: # 0 is error code for SUCCESS
 raise

Can you provide a test case for this?

Sorry for being a little bit slow to respond...
No I was not able to come up with a testcase that could generate this problem in a reproducible way on any Windows box I had. This problem sometimes occured on various OS versions, being probably a Windows oof configuration problem rather than the problem of the Python code itself. Nevertheless, changing it as I described above didn't cause any adverse side effects, at least for me.

I'm not sure how we take this forward as the code was changed via #11750, can somebody please advise.

Though the code may have changed a bit in the meantime (Issue11750 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:
1. A WindowsError exception is raised only if the Windows function SetNamedPipeHandleState returns 0.
2. The Windows function SetNamedPipeHandleState only returns 0 if it failed.
3. When that function fails, the Windows function GetLastError is expected to return a non-zero value to provide insight on the nature of the failure.
4. MSDN docs suggest that some functions may call SetLastError with 0 to indicate success (seen when subsequently calling GetLastError). This creates a bit of a conundrum given what the OP observed in the provided traceback: the Windows function SetNamedPipeHandleState failed yet the call to GetLastError returned a 0.
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.