Issue #14753: Make multiprocessing treat negative timeouts as it did in 3.2

In Python 3.2 and earlier, Process.join() and Connection.poll()
treated negative timeouts as zero timeouts.  Earlier versions from
the 3.3 line of development treat them as infinite timeouts.

The patch reverts to the old behaviour.

1 files changed, 7 insertions, 0 deletions

diff --git a/Doc/library/multiprocessing.rst b/Doc/library/multiprocessing.rst
index bdc07f1..320e492 100644
--- a/Doc/library/multiprocessing.rst
+++ b/Doc/library/multiprocessing.rst
@@ -928,6 +928,12 @@ object -- see :ref:`multiprocessing-managers`.
 
 .. note::
 
+   The :meth:`acquire` and :meth:`wait` methods of each of these types
+   treat negative timeouts as zero timeouts.  This differs from
+   :mod:`threading` where, since version 3.2, the equivalent
+   :meth:`acquire` methods treat negative timeouts as infinite
+   timeouts.
+
    On Mac OS X, ``sem_timedwait`` is unsupported, so calling ``acquire()`` with
    a timeout will emulate that function's behavior using a sleeping loop.
 
@@ -1899,6 +1905,7 @@ multiple connections at the same time.
    those objects in *object_list* which are ready.  If *timeout* is a
    float then the call blocks for at most that many seconds.  If
    *timeout* is ``None`` then it will block for an unlimited period.
+   A negative timeout is equivalent to a zero timeout.
 
    For both Unix and Windows, an object can appear in *object_list* if
    it is