[issue11668] _multiprocessing.Connection.poll with timeout uses polling under Windows

Antoine Pitrou added the comment: This is totally outdated by the new Connection implementation in 3.3. -- resolution: -> out of date stage: -> committed/rejected status: open -> closed superseder: -> Parent process hanging in multiprocessing if children terminate unexpectedly

[issue11668] _multiprocessing.Connection.poll with timeout uses polling under Windows

Antoine Pitrou added the comment: I have a full patch using overlapped I/O in issue9205 (sentinels3.patch). -- ___ Python tracker ___ ___

[issue11668] _multiprocessing.Connection.poll with timeout uses polling under Windows

Antoine Pitrou added the comment: A solution could be to use overlapped I/O on the named pipe handles. The first poll() would call ReadFile() with a tiny value (1?) and store an object wrapping the OVERLAPPED structure. Subsequent poll() or recv() would re-use that structure until the overlapp

[issue11668] _multiprocessing.Connection.poll with timeout uses polling under Windows

Antoine Pitrou added the comment: This doesn't seem to be so easy. WFMO (or WFSO) often seems to return successfully while there's no message to read on the pipe end. Here is a sample session (disturbing results): >>> a, b = connection.Pipe(True) >>> win32.WaitForMultipleObjects([a._handle],

[issue11668] _multiprocessing.Connection.poll with timeout uses polling under Windows

Antoine Pitrou added the comment: Are you sure about MP_EXCEPTION_HAS_BEEN_SET? semaphore.c has a more sophisticated logic: Py_BEGIN_ALLOW_THREADS ResetEvent(sigint_event); res = WaitForMultipleObjects(2, handles, FALSE, msecs); Py_END_ALLOW_THREADS /* h

[issue11668] _multiprocessing.Connection.poll with timeout uses polling under Windows

Kristján Valur Jónsson added the comment: I don't think it is necessary to have the initial call to PeekNamedPipe. It is a kernel call just like WFMO and so just as expensive. It also has some strange semantics, (such as being possibly blocking in a multithreaded application. read the docs

[issue11668] _multiprocessing.Connection.poll with timeout uses polling under Windows

Brian Curtin added the comment: Attaching an initial patch implementing the same functionality but using WaitForMultipleObjects. Here's some details: WFMO takes an array of objects to wait on, which is the pipe handle and sigint_event which is a handle to an event which gets set when CTRL-C i

[issue11668] _multiprocessing.Connection.poll with timeout uses polling under Windows

Brian Curtin added the comment: SYNCHRONIZE comes for free on pipes created with CreateNamedPipe, so there's nothing to do there. I think it's more likely that we'll have to use WaitForMultipleObjects and include the pipe handle with a signal handler for Ctrl-C. I believe this is done elsewh

[issue11668] _multiprocessing.Connection.poll with timeout uses polling under Windows

Antoine Pitrou added the comment: For the record, the polling code is in conn_poll() in Modules/_multiprocessing/pipe_connection.c. Windows named pipes seem to be created in pure Python in Lib/multiprocessing/connection.py. -- ___ Python tracker <

[issue11668] _multiprocessing.Connection.poll with timeout uses polling under Windows

New submission from Antoine Pitrou : This impacts higher-level APIs such as Queue.get() with a positive timeout. I'm not sure whether it's easily possible to fix this. A Google search seems to suggest that the pipe could be opened with "SYNCHRONIZE" access rights (?) and then WaitForSingleObjec