Paul Goins (work) added the comment:
I'm just going to ping on this issue. It looks like this has just slipped off
the radar. I've seen the last diff and the code review, but it seems that this
just needs some final follow-up on the code review comments, no?
I could easily do
Paul Goins added the comment:
I don't know enough about those tests and how important they are considered.
My only concern would be with the increased risk of undetected breakage caused
by removing them from CI, but if people think the risk is negligible and/or
acceptable, it's
Paul Goins added the comment:
Also, to be clear, I understand what David is saying and don't disagree at all.
And if this really is Spectre related, it may be difficult to "go back" and
test a before case, so my last comment about "digging in" may be rather moot.
Paul Goins added the comment:
If we consider this to be the new normal... What about increasing the timeout
to accomodate? From what I could gather, builds were running around 13 minutes
or so before the changes, so the timeout wasn't much above actual exec time to
begin with. Maybe
Paul Goins added the comment:
For what it's worth as a newbie here, I'll add my 2 cents. (This is partially
copied from my mail on python-dev.)
The one thing which I did notice between the last builds which passed and the
current builds is, under the "10 slowest tests"
Paul Goins added the comment:
Good point, I forgot about WaitForMultipleObjectsEx; something like that seems
like it would be much simpler for the first 2 cases.
--
___
Python tracker
<https://bugs.python.org/issue21
Paul Goins added the comment:
Okay, I think I need to abandon my research into this. This does seem to have
quite an amount of complexity to it and is probably more than I should be
taking on at this point in time.
Anyone else who wants to look at this, consider it fair game.
Parting
Paul Goins added the comment:
Ahh, thanks for the explanation. I didn't think about that. Let's *not* do
that then. :)
I'll see if I can squeeze in some time to play with the alternatives.
--
___
Python tracker
<https
Paul Goins added the comment:
> I think adding polling to such a widely-used primitive is out of question.
I'm guessing this is because of the perceived performance impact? (That's the
main thought I have against polling in this case.) Or is it something else?
I can cert
Paul Goins added the comment:
Focusing on the Windows case specifically... One way to possibly make this
work (although perhaps not as clean as may be desired) would be to add polling
logic into the thread_nt.h version of PyThread_acquire_lock_timed.
That would have the benefit of avoiding
Paul Goins added the comment:
Not sure if I'll do the full fix (need to check w/ my employer), but I'm doing
some investigation. Here's what I know so far:
At the Python level, the KeyboardInterrupt is being raised within
_wait_for_tstate_lock, on "elif lock.acquire(bloc
Paul Goins added the comment:
I've confirmed this issue on Windows. Attached is an SSCCE which seems to
reliably reproduce the issue in a Windows environment.
Long story short: if a KeyboardInterrupt occurs during Thread.join(), there's a
good chance that Thread._is_stopped neve
Paul Goins added the comment:
Ack; missed that. Thanks, and sorry for the noise.
--
___
Python tracker
<http://bugs.python.org/issue31058>
___
___
Python-bug
New submission from Paul Goins:
If modules are added to a package namespace at runtime, there is a chance that
they will not be properly detected if adding the module does not also result in
an update to the parent directory's st_mtime attribute.
This manifests in not being able to impor
New submission from Paul Goins <[EMAIL PROTECTED]>:
Just got Python 3.0 final on Windows and was testing out IDLE, and it's
having some issues.
Specifically:
* Options -> Configure IDLE..., General Tab:
Change Default Source Encoding from None to UTF-8
* Create a new python fi
15 matches
Mail list logo
