Closed lschoe closed 6 months ago
I do not understand what causes this problem however if I could find a clean way to debug this issue that would be very helpful I guess a deep dive into how each handle behaves would allow me to find a way to solve this issue. There should be a built-in way to debug these modules since they came from uvloop originally...
See the discussion for issue #13, for why the above workaround is no longer needed;)
You probably want to check the entire source code for similar cases. Maybe things like uv.ENOBUFS
and uv.ECANCELED
need to be handled similarly.
Hi, I've been testing Winloop and I was happy to see similar performance speedups on Windows as for uvloop on Linux. Really nice!
To get full functionality for my application I had to use two simple workarounds though, to fix two problems with Winloop 0.1.0.
The first problem happens upon closing a TCP connection. An error UV_EOF occurs on one side of the connection. The workaround is to simply ignore this exception. This error does not happen with any of the other event loops (asyncio's proactor, selector, nor with uvloop).
You can reproduce the problem running the simplest demo for the MPyC package. The following code is from the latest version MPyC v0.9.7 on GitHub, see mpyc/asyncoro.py. This is inside the
connection_lost(exc)
method:Using
python helloworld.py -M2 --output-file -E1
inmpyc/demos
runs the demo between two parties on localhost. Party 0 experiences no problems, but party 1 will get the 4095 error upon closing the TCP connection. The fileparty2_1.log
created will show the error in its last line. (Note that party 1 used a server listening for incoming connections from party 0, so party 0 acts as client and party 1 as server.)The problem does not happen when using SSL, which makes sense as an SSL transport has
can_write_eof() == False
.Do you have any idea what causes this problem?
For the other problem I'll open a separate issue.