_multiprocessing.Connection.poll with timeout uses polling under Windows

[pitrou]

BPO	11668
Nosy	@pitrou, @kristjanvalur, @tjguk, @briancurtin
Superseder	bpo-9205: Parent process hanging in multiprocessing if children terminate unexpectedly
Files	issue11668.diff

^{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:

assignee = 'https://github.com/briancurtin'
closed_at = <Date 2012-04-01.14:03:25.955>
created_at = <Date 2011-03-25.00:27:34.380>
labels = ['performance']
title = '_multiprocessing.Connection.poll with timeout uses polling under Windows'
updated_at = <Date 2012-04-01.14:03:25.954>
user = 'https://github.com/pitrou'

bugs.python.org fields:

activity = <Date 2012-04-01.14:03:25.954>
actor = 'pitrou'
assignee = 'brian.curtin'
closed = True
closed_date = <Date 2012-04-01.14:03:25.955>
closer = 'pitrou'
components = []
creation = <Date 2011-03-25.00:27:34.380>
creator = 'pitrou'
dependencies = []
files = ['21405']
hgrepos = []
issue_num = 11668
keywords = ['patch']
message_count = 10.0
messages = ['132058', '132059', '132069', '132215', '132217', '132238', '135393', '135434', '135494', '157289']
nosy_count = 6.0
nosy_names = ['pitrou', 'kristjan.jonsson', 'tim.golden', 'jnoller', 'brian.curtin', 'asksol']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = '9205'
type = 'resource usage'
url = 'https://bugs.python.org/issue11668'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3']

[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 WaitForSingleObject() be used on the handle.

[pitrou]

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.

[briancurtin]

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 elsewhere in the code, timemodule comes to mind (for sleep).

I'll see what I can come up with.

[briancurtin]

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 is caught (see Modules/_multiprocessing/multiprocessing.c). Waiting for both objects replaces the need to write a custom loop which periodically calls PyErr_CheckSignals.

A negative timeout was effectively a blocking call, so we can let WFMO handle that with an INFINITE timeout setting.

WFMO returns the object which raised it relative from event 0, so the switch case for a CTRL-C is 0+1 and returns the same value as before. If the pipe was the object to raise, just like before: return true if there's data, false if not.

[kristjanvalur]

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...). Just go for the WFMO to keep things simple.

[pitrou]

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

    /* handle result */
    if (res != WAIT_OBJECT_0 + 1)
        break;

    /* got SIGINT so give signal handler a chance to run */
    Sleep(1);

    /* if this is main thread let KeyboardInterrupt be raised */
    if (PyErr_CheckSignals())
        return NULL;

        /* recalculate timeout */
        if (msecs != INFINITE) {
            ticks = GetTickCount();
            if ((DWORD)(ticks - start) >= full_msecs)
                Py_RETURN_FALSE;
            msecs = full_msecs - (ticks - start);
        }

[pitrou]

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], True, 1000)
258
>>> win32.WaitForMultipleObjects([b._handle], True, 1000)
0
>>> win32.PeekNamedPipe(a._handle)
(0, 0)
>>> win32.WaitForMultipleObjects([a._handle], True, 1000)
0

(do note how the end created with CreateFile() is considered ready by WaitForMultipleObjects, while the end created with CreateNamedPipe() is considered ready after an unsuccessful call to PeekNamedPipe()!)

[pitrou]

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 overlapped read succeeds.
The hEvent in the OVERLAPPED structure should be usable in WFMO fine.

[pitrou]

I have a full patch using overlapped I/O in bpo-9205 (sentinels3.patch).

[pitrou]

This is totally outdated by the new Connection implementation in 3.3.