Richard Oudkerk shibt...@gmail.com added the comment:
How would this differ from the normal communicate()?
It would block until one of the following occurs:
* some data has been written to stdin,
* some data has been read from stdout or stderr, or
* timeout passes (if timeout is not None
Changes by Richard Oudkerk shibt...@gmail.com:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14881
___
___
Python-bugs-list mailing
Richard Oudkerk shibt...@gmail.com added the comment:
Comments on Josiah's patch:
* It uses pywin32 for PeekNamedPipe -- this is now available from _winapi.
* I don't think send(), recv() and recv_exact() will work correctly if
buffering is used -- an error should be raised in this case
Richard Oudkerk shibt...@gmail.com added the comment:
Personally, I would factor out the code for Popen.communicate() in to a
Communicator class which wraps a Popen object and has a method
communicate(input, timeout=None) - (bytes_written, output, error)
On Windows this would use threads
Richard Oudkerk shibt...@gmail.com added the comment:
I think the note for communicate() just means that you might get MemoryError
(or some other exception) if the output is too big. But I agree it is
ambiguous.
communicate() uses select() on Unix and threads on Windows, so deadlocks should
Richard Oudkerk shibt...@gmail.com added the comment:
PCbuild/build.bat and Modules/_decimal/tests/runall.bat still use vcbuild
instead of msbuild.
It also seems that if an external dependency is unavailable then msbuild can
fail to build targets which do not depend on it. For instance if I
Richard Oudkerk shibt...@gmail.com added the comment:
Failure to build _multiprocessing will mean that multiprocessing cannot
be imported. So if the function goes somewhere in multiprocessing then
it makes running the test suite with multiple processes dependent on the
building
Richard Oudkerk shibt...@gmail.com added the comment:
- the function generating the flags should be exported (with a private
name), so that it can be reused by Lib/test/[test_]support.py. Duplicate
code is error-prone, especially when enumerating command-line flags,
attribute names
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14753
New submission from Richard Oudkerk shibt...@gmail.com:
In version 3.2 and earlier, Process.join() and Connection.poll() treat negative
timeouts as zero timeouts. (Thread.join() does the same.)
In the current 3.3 version, they treat negative timeouts as infinite timeouts.
Also
Richard Oudkerk shibt...@gmail.com added the comment:
I've recently started seeing this failure repeatably on Linux (Ubuntu
Jaunty):
The test is newly enabled. Does repeatably mean you always get the failure?
I have not seen any failures on the Linux buildbots
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14725
Richard Oudkerk shibt...@gmail.com added the comment:
I found a race where a connection attempt could happen before the listening
socket's listen() method was called.
Vinay, could you update and try again please.
--
___
Python tracker rep
Richard Oudkerk shibt...@gmail.com added the comment:
The documentation page for ConnectNamedPipe
(http://msdn.microsoft.com/en-us/library/windows/desktop/aa365146(v=vs.85).aspx)
has a community addition which says that ConnectNamedPipe will appear to
fail with ERROR_NO_DATA (232) if a client
Richard Oudkerk shibt...@gmail.com added the comment:
TBH I don't understand why it should crash, and therefore how your patch
helps. Trying again using narrow strings should always work; indeed, the
code did that before I touched it. Can you describe how it crashes?
The important part
Richard Oudkerk shibt...@gmail.com added the comment:
Without the check for RuntimeError
os.utime(foo, times=(5,5), ns=(5,5))
raises
TypeError(TypeError: 'str' does not support the buffer interface)
because we have fallen through to the narrow path. The correct error
Richard Oudkerk shibt...@gmail.com added the comment:
Let me recap, just to make sure I have it straight. There are two errors
on Windows:
That's right. The patch looks good and passes for me on Windows.
--
___
Python tracker rep
Richard Oudkerk shibt...@gmail.com added the comment:
There is another problem causing a fatal error in test_posix on Unix.
The attached patch fixes it: *ua-path should be decrefed not ua-path.
--
Added file: http://bugs.python.org/file25452/utime_read_time_arguments.patch
Richard Oudkerk shibt...@gmail.com added the comment:
Looks good to me. You're a core contributor, yes? If not let me know and
I'll commit it.
I will commit.
Though I must admit I'm baffled how I haven't seen that crash. I've run
the unit tests a zillion times on this patch.
Were you
Richard Oudkerk shibt...@gmail.com added the comment:
I'm developing on Linux (64-bit) in case that helps.
I tested it on 32 bit Linux.
I have committed it, but I forgot to put the issue number in the commit message.
--
___
Python tracker rep
Richard Oudkerk shibt...@gmail.com added the comment:
bba131e48852 causes crashes on Windows.
The attached patch fixes the crash and makes test_os pass for me.
However, using PyErr_ExceptionMatches(PyExc_RuntimeError) to check whether to
try again using narrow strings is ugly. Maybe
Richard Oudkerk shibt...@gmail.com added the comment:
I have backported the fix for issue #9244 to 2.7. This should fix the hang and
produce a traceback containing a representation of the original error.
--
___
Python tracker rep...@bugs.python.org
Richard Oudkerk shibt...@gmail.com added the comment:
There are plenty of other bad exception classes apart from
CalledProcessError, including TimeoutExpired in the same file. In fact I
suspect this is true of the majority of the exception classes in the stdlib
which override __init__. So I
Richard Oudkerk shibt...@gmail.com added the comment:
The problems with error numbers seem to be caused by the addition of a new
section in errno.h:
/* POSIX SUPPLEMENT */
#define EADDRINUSE 100
#define EADDRNOTAVAIL 101
...
#define ETXTBSY 139
#define EWOULDBLOCK 140
Richard Oudkerk shibt...@gmail.com added the comment:
According to http://msdn.microsoft.com/en-us/library/5814770t.aspx the
supported errno values in VS2010 are
E2BIG EACCES EAGAIN EBADF ECHILD EDEADLOCK EDOM EEXIST EILSEQ
EINVAL EMFILE ENOENT ENOEXEC ENOMEM ENOSPC ERANGE EXDEV
Richard Oudkerk shibt...@gmail.com added the comment:
the errno codes (EAGAIN etc) are provided only as a compatibility for
posix apps that test errno. On windows, we use the WSA return values
from the api functions and WsaGetLastError().
...
So, the proposed patch is not a change
Richard Oudkerk shibt...@gmail.com added the comment:
New patch which adds timeout to ResourceSharer.stop() which defaults to 0.
When stop() fails it now uses the logger.
pthread_sigmask() only stops this background thread from receiving signals.
Signals will still be delivered to other
Richard Oudkerk shibt...@gmail.com added the comment:
This doesn't change that, and as far as I know, this has worked and
continues to work. errno is supported.
Using your patch, does the following throw an AssertionError?
import os, errno
try:
... os.read(-1, 10)
... except OSError
Richard Oudkerk shibt...@gmail.com added the comment:
I can't work out what is wrong here.
The code does not to account for a partial read of the message from the socket.
The attached patch fixes that, but it does not address the cause of this
failure.
--
keywords: +patch
Added file
Richard Oudkerk shibt...@gmail.com added the comment:
New version of patch which does
signal.pthread_sigmask(signal.SIG_BLOCK, range(1, signal.NSIG))
in the thread (is that right?).
It also uses a timeout when trying to join the thread.
--
Added file: http://bugs.python.org
Richard Oudkerk shibt...@gmail.com added the comment:
Warning added to patch.
--
Added file: http://bugs.python.org/file25362/mp_resource_sharer_stop.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14666
Richard Oudkerk shibt...@gmail.com added the comment:
Version of patch which checks invariants in the setter and adds tests.
--
Added file:
http://bugs.python.org/file25363/writable_closure_with_checking.patch
___
Python tracker rep
Richard Oudkerk shibt...@gmail.com added the comment:
Shouldn't test___closure__() also test what happens when the closure is
replaced with None, or a tuple which is too long or too short or contains
non-cell objects?
All of these things seem to be checked when you create a new function using
Richard Oudkerk shibt...@gmail.com added the comment:
The patch causes crashes. If I define
def cell(o):
def f(): o
return f.__closure__[0]
def f():
a = 1
b = 2
def g():
return a + b
return g
g = f()
then I find
g.__closure__ = None; g
Richard Oudkerk shibt...@gmail.com added the comment:
This patch adds a ResourceSharer.stop() method. This is called from
tearDownClass() in the unittest.
--
keywords: +patch
Added file: http://bugs.python.org/file25357/mp_resource_sharer_stop.patch
Richard Oudkerk shibt...@gmail.com added the comment:
I don't think _DummyThread can override __stop(), because of the name
mangling of __private methods. However, the hasattr() approach would
probably work.
Wouldn't a _DummyThread._Thread__stop() method override Thread.__stop()? Like
701 - 736 of 736 matches
Mail list logo
