[pypy-dev] slow-ish multithreaded primitives

[Dima Tisnek]

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