- 18 Jan, 2018 6 commits
-
-
Jason Madden authored
-
Jason Madden authored
[skip appveyor]
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
- 17 Jan, 2018 7 commits
-
-
Jason Madden authored
GEVENTSETUP_EV_VERIFY has to be set when gevent is compiled. Move it from the 'leaktest' target down to where we call develop
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
- 15 Jan, 2018 11 commits
-
-
Jason Madden authored
-
Jason Madden authored
-
Jason Madden authored
-
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.
-
- 14 Jan, 2018 2 commits
-
-
Jason Madden authored
correct a typo in src/gevent/greenlet.py [skip ci]
-
Felix Yan authored
-
- 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 4 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
-