Fix #1127 by interpreting -1 as None under libuv for select.poll.poll; should...

Fix #1127 by interpreting -1 as None under libuv for select.poll.poll; should probably start having Timeout do that itself.

CHANGES.rst

@@ -131,6 +131,12 @@
   not previously supported, is not possible now. See
   :issue:`1226`.
 
+- :meth:`gevent.select.poll.poll` now interprets a *timeout* of -1 the
+  same as a *timeout* of *None* as the standard requires. Previously,
+  on libuv this was interpreted the same as a *timeout* of 0. In
+  addition, all *timeout* values less than zero are interpreted like
+  *None* (as they always were under libev). See :issue:`1127`.
+
 1.3a1 (2018-01-27)
 ==================
 

src/gevent/event.py

@@ -114,7 +114,7 @@ class _AbstractLinkable(object):
                     # rely on the exact return values, not just truthish-ness
                     return False
             finally:
-                timer.cancel()
+                timer.close()
         finally:
             self.unlink(switch)
 

src/gevent/select.py

@@ -2,7 +2,7 @@
 """
 Waiting for I/O completion.
 """
-from __future__ import absolute_import
+from __future__ import absolute_import, division, print_function
 
 import sys
 
@@ -230,6 +230,10 @@ if original_poll is not None:
 
             .. versionchanged:: 1.2a1
                File descriptors that are closed are reported with POLLNVAL.
+
+            .. versionchanged:: 1.3a2
+               Under libuv, interpret *timeout* values less than 0 the same as *None*,
+               i.e., block. This was always the case with libev.
             """
             result = PollResult()
             watchers = []
@@ -241,7 +245,20 @@ if original_poll is not None:
                     watchers.append(watcher)
                     watcher.priority = MAXPRI
                     watcher.start(result.add_event, fd, pass_events=True)
-                if timeout is not None and timeout > -1:
+                if timeout is not None:
+                    if timeout < 0:
+                        # The docs only say specifically that -1 itself
+                        # is supposed to block forever. Many, but not all
+                        # OS's accept any negative number to mean that. Some
+                        # OS's raise errors for anything negative but not -1.
+                        # Python 3.7 changes to always pass exactly -1 in that
+                        # case from selectors.
+                        # Our Timeout class currently does not have a defined behaviour
+                        # for negative values. On libuv, it uses a check watcher and effectively
+                        # doesn't block. On libev, it seems to block. In either case, we
+                        # *want* to block, so turn this into the sure fire block request.
+                        timeout = None
+                    elif timeout:
                         timeout /= 1000.0
                 result.event.wait(timeout=timeout)
                 return list(result.events)

src/greentest/greentest/patched_tests_setup.py

@@ -270,18 +270,6 @@ if LIBUV:
             # crashes with EPERM, which aborts the epoll loop, even
             # though it was allowed in in the first place.
             'test_asyncore.FileWrapperTest.test_dispatcher',
-
-            # XXX Debug this.
-            # Fails on line 342:
-            #  self.assertEqual(1, len(s.select(-1)))
-            # AssertionError 1 != 0
-            # Is the negative time not letting the loop cycle or something?
-            # The -1 currently passes all the way through select.poll to
-            # gevent.event.Event.wait to gevent.timeout.Timeout to gevent.libuv.loop.timer
-            # to gevent.libuv.watchers.timer,  where I think it is reset to 0.001.
-            # Alternately, this comes right after a call to s.select(0); perhaps libuv
-            # isn't reporting twice? We cache the watchers, maybe we need a new watcher?
-            'test_selectors.PollSelectorTestCase.test_timeout',
         ]