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 wrote:
> Can I try to make a case for
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
Hi Dima,
On 25 February 2014 16:45, Dima Tisnek 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() c
Armin, is there really a semantical change?
Consider invocations valid in 2.7, (i.e. without timeout argument), is
it not the same then?
I'd rather see improvement to existing python programs :)
should this code be in nightly builds?
my original use case was much more convoluted than the minimal t
Hi,
On 23 February 2014 19:54, Maciej Fijalkowski wrote:
> On Sun, Feb 23, 2014 at 6:57 PM, Mark Roberts wrote:
>> How hostile would you be to a pypy-2.8 branch with these kinds of
>> improvements?
>
> we don't need a 2.8 branch to do that, we can just commit stuff to
> master (that's still pyt
On Sun, Feb 23, 2014 at 6:57 PM, Mark Roberts wrote:
> How hostile would you be to a pypy-2.8 branch with these kinds of
> improvements?
we don't need a 2.8 branch to do that, we can just commit stuff to
master (that's still python 2.7)
___
pypy-dev ma
How hostile would you be to a pypy-2.8 branch with these kinds of improvements?
-Mark
> On Feb 23, 2014, at 1:04, Armin Rigo wrote:
>
> Hi Dima,
>
>> On 22 February 2014 20:51, Dima Tisnek wrote:
>> Right, I narrowed it down to condition.wait being much slower with a
>> timeout than without.
Hi Dima,
On 22 February 2014 20:51, Dima Tisnek wrote:
> Right, I narrowed it down to condition.wait being much slower with a
> timeout than without.
Thanks! Fixed. Indeed, I simply took the version of lock.acquire()
from the py3k branch (with support for timeout and interrupts), and
applied i
Right, I narrowed it down to condition.wait being much slower with a
timeout than without.
see attached test script.
On 22 February 2014 08:20, Armin Rigo wrote:
> Hi Dima,
>
> On 21 February 2014 15:43, Dima Tisnek wrote:
>> sorry I don't have code handy, it's part of a larger project, but
Hi Dima,
On 21 February 2014 15:43, Dima Tisnek wrote:
> sorry I don't have code handy, it's part of a larger project, but if
> someone's interested, please reply and I'll hack up a short test case.
Please do.
Armin
___
pypy-dev mailing list
pypy-dev
Hey all, I wrote some threaded code and ran it under different version
of python, and unexpectedly high overhead is observed:
cpython 2.6.8. cpython 2.7.6, pypy 2.2.1: 14~53ms
cpython 3.3.4: pypy 2.1.0 beta py3 mode: <1ms
is someone here interested in getting to the bottom of it?
or getting pypy
11 matches
Mail list logo
