GeezerVison

Windows refuses a single pipe write of more than 0xFFFFFFCF bytes, but may already have completed a read that the other end was waiting on, with ERROR_MORE_DATA and nothing left in the pipe; that reader then fails at assert left > 0 in PipeConnection._get_more_data(). As discussed in #161668, this checks the size in PipeConnection._send_bytes() before anything is written and raises ValueError, the exception the documentation of send() and send_bytes() names. Supporting larger messages needs a header that stays compatible between Python versions and is left for later. The check uses the measured limit; a round margin such as 0xFFFF0000 would be a one-line change.

test_send_bytes_too_large lowers the limit and runs without -M; test_send_bytes_too_large_for_windows is a bigmemtest (-M 4G; it holds one 4 GiB buffer at a time) with the real sizes. Both give a receiver thread 0.1 s to block in recv_bytes() before the oversized send, then check that it gets the next message; the first also sends a message of exactly the limit. Without the change the first fails with "ValueError not raised" and the second with OSError: [WinError 87]. I also checked on a debug build that a message of exactly 0xFFFFFFCF bytes still arrives whole, and that a Pool worker survives a task that is too large and runs the next one.

• Issue: multiprocessing: on Windows, a message over 4,294,967,247 bytes raises OSError and breaks a waiting receiver #161668