To help get an idea of the racing condition I created a trace with several additional debug outputs in pool.py and connection.py

"======= Creating new pool =======" marks a new start of a pool using the Pool.imap() function. The iteration is terminated at some time and a new pool is created with a new call to imap(). The last log entry shows the location of the last call which currently hangs endlessly.

I am not a multithreading/winapi expert so I could not fix the actual issue with _winapi.WaitForMultipleObjects but the fix in the PR actually ignores preceding issues when polling more data than actually needed for the two sentinels.

Remark: I have also seen this issue in linux with the same application but was not able to debug it so far.