[pypy-dev] slow-ish multithreaded primitives

Dima Tisnek dimaqq at gmail.com
Mon Mar 10 10:19:38 CET 2014

Oh, so sorry to have jumped the gun.

now that I properly tested the nightly build I see that the
performance issue I saw is gone and that condition.acquire actually
calls _py3k_acquire when timeout argument is present.


On 10 March 2014 09:38, Dima Tisnek <dimaqq at gmail.com> wrote:
> 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()
> with c:
>     while something:
>         c.wait(some time)
>     change state
> with c:
>     c.notifyAll()
> What is the semantic difference in the choice of the underlying
> implementation of c._Condition__lock._RLock__block.acquire vs
> _py3k_acquire?
> what could go wrong if c._Condition_lock.__enter__ was mapped to
> _py3k_acquire instead?
> 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?
> d.
> 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?
>> Yes.
>> Armin

More information about the pypy-dev mailing list