- 15 Jan, 2018 8 commits
-
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
This lets us start using our infrastructure for flaky timeouts.
-
Jason Madden authored
Make Timeout._start_new_or_dummy stop forcing the issue. The failing test_telnetlib was fixed by avoiding a zero-duration timer. On libuv zero duration timers can block the event loop.
-
Jason Madden authored
libev follows libuv by not updating the loop time in a timer by default. A Timeout that we use internally still does this though.
-
- 13 Jan, 2018 2 commits
-
-
Jason Madden authored
Let the Timeout class update the loop time when used internally. Otherwise, test_telnetlib.py 'hangs'. Not exactly clear why, but at a guess apparently we're not getting out of the timer callback loop.
-
Jason Madden authored
libuv: do not update the loop time when timers are started by default. See #1057. libev might follow suite in the future.
-
- 12 Jan, 2018 6 commits
-
-
Jason Madden authored
But see the comments in the code and the comments in the issue. libuv has very different timer behaviour than libev.
-
Jason Madden authored
It depended on when the timer expired relative to when we intered the loop for the first time. It could still run before our other callbacks did if it had expired before we entered the loop. I suppose that going to the static 'extern' functions changed the timing of things enough that this exposed itself.
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
I'll need help to reproduce them. But temporarily add some extra debugging to the makefile to see if we get a clue. The cpython failure in test_subprocess.py definitely began with this branch (which doesn't make much sense). The PyPy failure was happening long before.
-
- 11 Jan, 2018 2 commits
-
-
Jason Madden authored
-
Jason Madden authored
-
- 10 Jan, 2018 5 commits
-
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
Skip that one test that fails on Python 3.7 under libuv on Travis. It doesn't fail for any other CPython version there and it doesn't fail locally. Chalking it up to a alpha issue for now.
-
Jason Madden authored
-
Jason Madden authored
Instead of manually having it schedule callbacks, we instead run callbacks at a time in the event loop cycle equivalent to when libev runs them. We do this with a check watcher (instead of a 0 duration timer). Fixes #1058
-
- 09 Jan, 2018 6 commits
-
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
The good news is this probably explains a lot of the timer oddities we see under libuv (see detailed comments in the code). The bad news is it means we need to rethink some things for libuv.
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
Test all backends that are supported with the full test suite in a single run. We have a high setup overhead, so not only does this reduce the number of jobs, it hopefully reduces the overall time taken, while actually increasing the number of tests run.
-
- 08 Jan, 2018 7 commits
-
-
Jason Madden authored
Support for Python 3.7
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
No new unexpected failures. Rename the 'async' methods and classes to 'async_'. I couldn't think of a better name. But keep the old names available for BWC. Fixes #1047.
-
- 02 Jan, 2018 1 commit
-
-
Jason Madden authored
Request more specifics.
-
- 22 Dec, 2017 3 commits
-
-
Jason Madden authored
Explicitly close IO watchers
-
Jason Madden authored
Disable PyPy+libuv on Windows again, still some very strange errors there. But PyPy+libuv on darwin/posix works, and CPython3.6 Windows works. Perhaps the issue is the 32-bit pypy on windows and the way it adjusts socket.fileno()?
-
Jason Madden authored
-