[pypy-dev] slow-ish multithreaded primitives
dimaqq at gmail.com
Mon Mar 10 09:38:57 CET 2014
Can I try to make a case for _py3k_acquire inclusion when using
context manager API?
Let's say a well-formed Python program always context managers, and
thus timeouts are only supplied to condition,wait():
c = threading.Condition()
What is the semantic difference in the choice of the underlying
implementation of c._Condition__lock._RLock__block.acquire vs
what could go wrong if c._Condition_lock.__enter__ was mapped to
AFAIK context manager API doesn't allow user to pass blocking=0 here.
Thus lock acquisition cannot time out. Seems pretty solid to me...
That still leaves signal handling. Is the concern here about the
context in which signal handler executes? the behaviour of user
program because signal may be caught earlier? unexpected exception
site for KeyboardInterrupt?
On 27 February 2014 15:54, Armin Rigo <arigo at tunes.org> wrote:
> Hi Dima,
> On 25 February 2014 16:45, Dima Tisnek <dimaqq at gmail.com> wrote:
>> Armin, is there really a semantical change?
>> Consider invocations valid in 2.7, (i.e. without timeout argument), is
>> it not the same then?
> It's different: Python 3.x acquire() can be interrupted by signals,
> whereas Python 2.x acquire() cannot.
>> should this code be in nightly builds?
More information about the pypy-dev