[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.

d.

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