Reid Kleckner r...@mit.edu added the comment:
Thanks for fixing the negative timeout issue. I assumed incorrectly that a
negative timeout would cause it to check and return immediately if it would
otherwise block.
As for the docs, the 3.2/3.3 issue was fixed in [[72e49cb7fcf5]].
I just
Reid Kleckner r...@mit.edu added the comment:
I think the best behavior would be to go ahead and check one last time before
raising the exception, so _remaining_time should turn a negative value into 0
(assuming that a timeout value of zero does the right thing for our use case).
If people
Reid Kleckner r...@mit.edu added the comment:
The bot is green again as of ab2363f89058. Thanks for the heads up.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11613
Reid Kleckner r...@mit.edu added the comment:
It is necessary, WaitForSingleObject takes its argument in
milliseconds. It will make the exception message wrong, though, which
I can fix.
Reid
On Sun, Mar 20, 2011 at 1:46 PM, Santoso Wijaya rep...@bugs.python.org wrote:
Santoso Wijaya
Reid Kleckner r...@mit.edu added the comment:
:( Thanks for spotting these. Is there an easier way for me to be notified if
these particular tests fail? Some of these are not in the stable builder set.
Sorry to leave the builders broken for so long. I just upped the timeouts to 3
seconds
Reid Kleckner r...@mit.edu added the comment:
I updated and committed the patch to the cpython hg repo in revision
[c4a0fa6e687c].
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5673
Reid Kleckner r...@mit.edu added the comment:
On Mon, Mar 14, 2011 at 12:31 PM, Sridhar Ratnakumar
rep...@bugs.python.org wrote:
Sridhar Ratnakumar sridh...@activestate.com added the comment:
On 2011-03-14, at 9:18 AM, Reid Kleckner wrote:
I updated and committed the patch to the cpython
Changes by Reid Kleckner r...@mit.edu:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5673
___
___
Python-bugs-list
Reid Kleckner r...@mit.edu added the comment:
I can't reproduce this. I've tested on:
64-bit Linux (Debian lenny)
OS X 10.6
Windows Vista 32-bit
It seems reasonable to me that the interpreter should be able to
initialize and write to stdout in less than half a second, but it
seems
Reid Kleckner r...@mit.edu added the comment:
I increased the timeout in [fd2b3eac6756] and the buildbot is passing now:
http://python.org/dev/buildbot/all/builders/x86%20debian%20parallel%203.x
--
status: open - closed
___
Python tracker rep
Reid Kleckner r...@mit.edu added the comment:
Looks good to me. Do you need the TODO(gps)'s in there after implementing the
behavior described?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054041
Reid Kleckner r...@mit.edu added the comment:
Pablo, so if I understand the issue you've run into correctly, you are using
shell redirection to redirect stdout to a file, and then attempting to read
from it using stdout=subprocess.PIPE.
It seems to me like this behavior is expected, because
Reid Kleckner r...@mit.edu added the comment:
No, sorry, I just haven't gotten around to reproducing it on Linux.
And I've even needed this functionality in the mean time, and we worked around
it with the standard alarm trick! =/
--
___
Python
Reid Kleckner r...@mit.edu added the comment:
Added a patch that adds support for recomputing the timeout, plus a test for it.
Can this still make it into 3.2, or is it too disruptive at this point in the
release process?
--
Added file: http://bugs.python.org/file18536/lock-interrupt
Reid Kleckner r...@mit.edu added the comment:
On Thu, Jul 22, 2010 at 9:05 AM, Alexander Belopolsky
rep...@bugs.python.org wrote:
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
The documentation should mention somewhere that timeout can be a float. For
example
Reid Kleckner r...@mit.edu added the comment:
When I ported the patch I tested on trunk + Windows to py3k, I messed that
stuff up. I also had to fix a bunch of str vs. bytes issues this time around.
On Windows, it uses TextIOWrapper to do the encoding, and on POSIX it uses
os.write, so I
Reid Kleckner r...@mit.edu added the comment:
pytime.h looks like it got pasted into the file twice. Other than that, it
looks good to me and the tests pass on OS X here.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
Reid Kleckner r...@mit.edu added the comment:
I think you used 'struct timeval *' in the function definition instead of
'_PyTimeVal *'.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
Reid Kleckner r...@mit.edu added the comment:
Uh oh, that was one of the fixes I made when I tested it on Windows. I may
have failed to pick up those changes when I ported to py3k. I'll check it out
tonight.
--
___
Python tracker rep
Changes by Reid Kleckner r...@mit.edu:
--
assignee: - rnk
keywords: +needs review -patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6643
Changes by Reid Kleckner r...@mit.edu:
--
assignee: - rnk
dependencies: +Throw away more radioactive locks that could be held across a
fork in threading.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6642
Reid Kleckner r...@mit.edu added the comment:
Waiting until the portability hacks for gettimeofday make it into core Python.
--
dependencies: +Make gettimeofday available in time module
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Reid Kleckner r...@mit.edu added the comment:
It's using the old Python 2 unicode string literal syntax.
It also doesn't keep to 80 cols.
I'd also rather continue using a lazily initialized dict instead of catching a
KeyError for apos;.
I also feel that with the changes to Unicode in py3k
Changes by Reid Kleckner r...@mit.edu:
--
nosy: +rnk
versions: +Python 3.2 -Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5872
Reid Kleckner r...@mit.edu added the comment:
I don't imagine this is going into 2.7.0 at this point, so I ported the patch
to py3k. I also added support to check_output for the timeout parameter and
added docs for all of the methods/functions that now take a timeout in the
module
Reid Kleckner r...@mit.edu added the comment:
I think you forgot to svn add pytime.c before making the diff.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
Reid Kleckner r...@mit.edu added the comment:
I forgot that I had to tweak the test as well as subprocess.py. I did a
.replace('\r', ''), but universal newlines is better.
Looking at the open questions I had about the Windows threads, I think it'll be
OK if the user follows the pattern
Reid Kleckner r...@mit.edu added the comment:
Right, it's one of the peculiarities of archive files (I think). When none of
an object file's symbols are used from the main program, the object file is
dropped on the floor, ie not included. This has bizarre consequences in C++
with static
Reid Kleckner r...@mit.edu added the comment:
I'd really rather not try to rely module loading from a threading primitive. :)
I think if you follow Antoine's suggestion of adding _PyTime_Init (which does
nothing in the body other than a comment) it should work fine
Reid Kleckner r...@mit.edu added the comment:
I went through the trouble of building and testing Python on Windows Vista, and
with some small modifications I got the tests I added to pass.
Here's an updated patch. I'm still not really sure how those threads work on
Windows, so I'd rather
Reid Kleckner r...@mit.edu added the comment:
Sorry, I was just posting it so Benjamin could see what this bought us. I'm
not pushing to get this in CPython.
The results are for JITed code. I forget what the interpreted results are. I
think they are good for the microbenchmarks
Reid Kleckner r...@mit.edu added the comment:
I have an patch for unladen-swallow out for review here:
http://codereview.appspot.com/160063/show
It resolves the correctness issues I mentioned previously by emitting guards if
necessary. If the type is predictable and uses slots, then we don't
Reid Kleckner r...@mit.edu added the comment:
I completely agree, but the cat is out of the bag on this one. I don't see how
we could get rid of fork until Py4K, and even then I'm sure there will be
people who don't want to see it go, and I'd rather not spend my time arguing
this point
Reid Kleckner r...@mit.edu added the comment:
Alternatively, do you think it would be better to ignore interrupts when a
timeout is passed? If a timeout is passed, the lock acquire will eventually
fail in a deadlock situation, and the signal will be handled in the eval loop.
However
Reid Kleckner r...@mit.edu added the comment:
The patch looks good to me FWIW.
I would be interested in using this perhaps in issue8844, which involves lock
timeouts. It may be true that the POSIX API uses nanoseconds, but pythreads
only exposes microsecond precision.
In order to use
Reid Kleckner r...@mit.edu added the comment:
This patch looks good to me, after digging through the relevant module code.
I was confused though for a bit as to why PyModuleDef is a PyObject with a NULL
type. It turns out that import.c wants to keep them in a dictionary, so it
needs
Changes by Reid Kleckner r...@mit.edu:
--
title: joining a child that forks can deadlock in the forked child process -
Throw away more radioactive locks that could be held across a fork in
threading.py
___
Python tracker rep...@bugs.python.org
http
Reid Kleckner r...@mit.edu added the comment:
Here's a patch that makes Python-level lock acquisitions interruptible for
py3k. There are many users of the C-level lock API, most of whom are not set
up to deal with lock acquisition failure. I decided to make a new API function
and leave
Reid Kleckner r...@mit.edu added the comment:
Here is a new version of a patch that updates recursive locks to have the same
behavior. The pure Python RLock implementaiton should be interruptible by
virtue of the base lock acquire primitive being interruptible.
I've also updated the relevant
Reid Kleckner r...@mit.edu added the comment:
Here's an updated patch for py3k (3.2). The test still fails without the fix,
and passes with the fix.
Thinking more about this, I'll try summarizing the bug more coherently:
When the main thread joins the child threads, it acquires some locks
Reid Kleckner r...@mit.edu added the comment:
Oops, copy/paste oversight. =/ I wrote a test to verify that it handles
signals, and then retries the lock acquire.
--
Added file: http://bugs.python.org/file17935/lock-interrupt.diff
___
Python
Reid Kleckner r...@mit.edu added the comment:
I realized that in a later fix for unladen-swallow, we also cleared the
condition variable waiters list, since it has radioactive synchronization
primitives in it as well.
Here's an updated patch that simplifies the fix by just using __init__
Reid Kleckner r...@mit.edu added the comment:
Also, thanks for the quick reviews!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8844
Reid Kleckner r...@mit.edu added the comment:
I'd like to fix it, but I don't know if I'll be able to in time. It was
something that bugged me while running the threading tests while working on
Unladen.
I'm imagining (for POSIX platforms) adding some kind of check for signals when
Reid Kleckner r...@mit.edu added the comment:
- why do you say Thread.join() uses a busy loop? is it because it uses
Condition.wait()? If so, this will be solved in py3k by issue7316 (which you
are welcome to review). Otherwise, I think there should be an upper bound on
the sleeping
Changes by Reid Kleckner r...@mit.edu:
--
nosy: +rnk
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6033
___
___
Python-bugs-list mailing list
Reid Kleckner r...@mit.edu added the comment:
One thing I was wondering about the current patch is what about objects
that have attributes that shadow methods? For example:
class C(object):
def foo(self):
return 1
c = c()
print c.foo()
c.foo = lambda: 2
print c.foo()
Shouldn't
Changes by Reid Kleckner r...@mit.edu:
--
nosy: +rnk
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1068268
___
___
Python-bugs-list mailing list
New submission from Reid Kleckner r...@mit.edu:
The test case is attached. On Mac OS X (and presumably FreeBSD, which
has the same behavior) when you try to exec from a process that has any
other threads in it, you get an OSError, Operation not supported.
Here's the output on my MacBook
Reid Kleckner r...@mit.edu added the comment:
Supposedly this bug also affects FreeBSD, but I can't verify it. I'd
say the problem isn't going away, at least not for that platform, but I
don't feel like it's worth bending over backwards to deal with it either.
As far as it concerns unladen
New submission from Reid Kleckner r...@mit.edu:
I attached a test case to reproduce.
Here is what it does:
- The main thread in the parent process starts a new thread and waits
for it.
- The child thread forks.
- The child process creates a daemon thread, and returns.
- The parent process
New submission from Reid Kleckner r...@mit.edu:
This bug is similar to the importlock deadlock, and it's really part of
a larger problem that you should release all locks before you fork.
However, we can fix this in the threading module directly by freeing and
resetting the locks on the main
Changes by Reid Kleckner r...@mit.edu:
--
versions: +Python 2.6 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6642
___
___
Python-bugs
Reid Kleckner r...@mit.edu added the comment:
Here's a patch for 3.2 which adds the fix and a test case. I also
verified that the problem exists in 3.1, 2.7, and 2.6 and backported the
patch to those versions, but someone should review this one before I
upload those.
--
keywords
Reid Kleckner r...@mit.edu added the comment:
Here's a patch against 2.6 for one way to fix it. I imagine it has
problems, but I wanted to throw it out there as a straw man.
This patch builds on the patch for http://bugs.python.org/issue6643
since some of the test cases will occasionally
New submission from Reid Kleckner r...@mit.edu:
I was looking for a way to run a subprocess with a timeout. While there
are a variety of solutions on Google, I feel like this functionality
should live in the standard library module. Apparently Guido thought
this would be good in 2005
Reid Kleckner r...@mit.edu added the comment:
Ugh. I made the assumption that there must be some natural and easy way
to wait for a child process with a timeout in C, and it turns out it's
actually a hard problem, which is why this isn't already implemented.
So my initial hack for solving
Reid Kleckner r...@mit.edu added the comment:
I'd like some feedback on this patch. Is the API acceptable?
Would it be better to throw an exception in wait() instead of returning
None?
What should communicate() return if it times out? I can't decide if it
should try to return partial
58 matches
Mail list logo
