Message318921
race.py: simple echo client and server sending packets in both directions. Pause/resume reading the client transport every 100 ms to trigger the bug.
Using ProactorEventLoop and 2000 packets of 16 KiB, I easily reproduce the bug.
So again, it's nothing related to start_tls(), start_tls() was just one way to spot the bug.
The bug is in Proactor transport: the cancellation of overlapped WSARecv() sometime drops packets. The bug occurs when CancelIoEx() fails with ERROR_NOT_FOUND which means that the I/O (WSARecv()) completed.
One solution would be to not cancel WSARecv() on pause_reading(): wait until the current WSARecv() completes, store data something but don't pass it to protocol.data_received()!, and no schedule a new WSARecv(). Once reading is resumed: call protocol.data_received() and schedule a new WSARecv().
That would be a workaround. I don't know how to really fix WSARecv() cancellation without loosing data. A good start would be to modify Overlapped.cancel() to return a boolean to notice if the overlapped I/O completed even if we just cancelled it. Currently, the corner case (CancelIoEx() fails with ERROR_NOT_FOUND) is silently ignored, and then the IOCP loop silently ignores the event of completed I/O... |
|
Date |
User |
Action |
Args |
2018-06-07 10:21:06 | vstinner | set | recipients:
+ vstinner, ned.deily, asvetlov, yselivanov, pablogsal |
2018-06-07 10:21:06 | vstinner | set | messageid: <1528366866.19.0.592728768989.issue33694@psf.upfronthosting.co.za> |
2018-06-07 10:21:06 | vstinner | link | issue33694 messages |
2018-06-07 10:21:05 | vstinner | create | |
|