Davin Potts added the comment:

In the docs for 2.7, multiprocessing.Lock refers to threading.Lock in which the 
signature for acquire looks like:

    threading.Lock.acquire([blocking])


However, in the current code in 2.7, Modules/_multiprocessing/semaphore.c 
implements multiprocessing.Lock.acquire to support two arguments:  'block' and 
'timeout'.


In the docs for 3.4, threading.Lock.acquire now has both 'blocking' and 
'timeout' arguments.  Notably, it specifies: "It is forbidden to specify a 
timeout when blocking is false."  This is indeed enforced by threading.Lock but 
not at all by multiprocessing.Lock.  In a 3.4.3 shell:

    >>> import multiprocessing
    >>> import threading
    >>> ml = multiprocessing.Lock()
    >>> ml.acquire(False, 20.0)
    True
    >>> ml.release()
    >>> tl = threading.Lock()
    >>> tl.acquire(False, 20.0)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: can't specify a timeout for a non-blocking call


In 2.7, acquire similarly permits a supplied value for timeout even when set to 
be non-blocking.

A further difference:  the code in Modules/_multiprocessing/semaphore.c appears 
to translate a timeout=None into an infinite wait whereas the threading 
implementation rejects any attempt to supply a None for timeout, demanding a 
float instead.  (In 3.4, threading uses timeout=-1 to request an infinite wait.)


Given these discrepancies between threading's and multiprocessing's 
implementations for Lock and given the difficulties in renaming an argument 
that can be supplied as a non-keyword parameter, the right thing to do at this 
point is to properly document multiprocessing.Lock's acquire as using 'block' 
and 'timeout'.

----------
assignee:  -> docs@python
components: +Documentation -Extension Modules
nosy: +docs@python

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to