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 <dim...@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 <ar...@tunes.org> wrote: >> Hi Dima, >> >> On 25 February 2014 16:45, Dima Tisnek <dim...@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 _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
