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@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@tunes.org> wrote:
Hi Dima,
On 25 February 2014 16:45, Dima Tisnek <dimaqq@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