Richard Oudkerk added the comment:
I think this is a duplicate of #17899.
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue18332>
___
___
Python-bug
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk added the comment:
Patch attached.
--
keywords: +patch
Added file: http://bugs.python.org/file30748/buf-readall.patch
___
Python tracker
<http://bugs.python.org/issue18
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
title: multiprocessing.pool.Pool task/worker handlers are not fork safe -> Pool
methods can only be used by parent process.
type: behavior ->
versions: +Python
Changes by Richard Oudkerk :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue14206>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue14206>
___
___
Pyth
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.or
Richard Oudkerk added the comment:
Reopening because I think this is again a problem for Win64 and 3.x. The Win64
buildbots always seem to crash on test_marshal (and I do too).
It appears to be BugsTestCase.test_loads_2x_code() which crashes, which is
virtually the same as
Richard Oudkerk added the comment:
Closing because this is caused by #17206 and is already discussed there.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Changes by Richard Oudkerk :
--
resolution: -> works for me
stage: test needed -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Richard Oudkerk added the comment:
> I think I know what's going on here. For socket IO readline() uses a
> readahead buffer size of 1.
Why is that? I think that makefile(mode='rb') and fdopen() both create
BufferedReader objects with the same buffer size.
It looks to
Richard Oudkerk added the comment:
Using
while True:
if not fileobj.read(8192):
break
instead of
for line in fileobj:
pass
results in higher throughput, but a similar slowdown with makefile(). So this
is not a problem specific to
Richard Oudkerk added the comment:
The only real reason for implementing SocketIO in pure Python is because read()
and write() do not work on Windows with sockets. (I think there are also a few
complications involving SSL sockets and the close() method.)
On Windows I have implemented a file
Richard Oudkerk added the comment:
Ah. I had not thought of socket timeouts.
--
___
Python tracker
<http://bugs.python.org/issue18329>
___
___
Python-bugs-list m
Richard Oudkerk added the comment:
I find that by adding the lines
fileobj.raw.readinto = ss.recv_into
fileobj.raw.read = ss.recv
the speed with makefile() is about 30% slower than with fdopen().
--
___
Python tracker
<h
Richard Oudkerk added the comment:
Shouldn't the child process be terminating using os._exit()?
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/i
Richard Oudkerk added the comment:
Does that test always fail?
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue18382>
___
___
Python-bugs-list mailin
Richard Oudkerk added the comment:
> - would improve POSIX compatibility, it mimics what os.pipe()
> does on those OS
I disagree.
On Windows fds can only be inherited if you start processes using the spanwn*()
family of functions. If you start them using CreateProcess() then the
unde
Richard Oudkerk added the comment:
Oops. I confused os.popen() with os.spawn*(). os.spawnv() IS still
implemented using spawnv() in Python 3.
--
___
Python tracker
<http://bugs.python.org/issue4
Changes by Richard Oudkerk :
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue18455>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Richard Oudkerk :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue18344>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue18344>
___
___
Richard Oudkerk added the comment:
Thanks for the report.
This should be fixed now in 2.7. (3.1 and 3.2 only get security fixes.)
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python track
Richard Oudkerk added the comment:
Thanks for the patches!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk added the comment:
You can do
sys.stdout.buffer.write(b"hello")
See
http://docs.python.org/dev/library/io.html?highlight=buffer#io.TextIOBase.buffer
--
nosy: +sbt
___
Python tracker
<http://bugs.python.o
Richard Oudkerk added the comment:
IMHO
1) It should check all predicates.
2) It should return a list of ready conditions.
3) It should *not* accept a list of conditions.
4) from_condition() should be removed.
Also notify() should try again if releasing a waiter raises RuntimeError
because it
Richard Oudkerk added the comment:
The spawn branch is in decent shape, although the documentation is not
up-to-date.
I would like to commit before the first alpha.
--
___
Python tracker
<http://bugs.python.org/issue8
Richard Oudkerk added the comment:
I played a bit with the patch and -v -Xshowrefcount. The number of references
and blocks left at exit varies (and is higher than for unpatched python).
It appears that a few (1-3) module dicts are not being purged because they have
been "orphaned&qu
Richard Oudkerk added the comment:
On 01/08/2013 10:59am, Antoine Pitrou wrote:
> If you replace the end of your script with the following:
>
> for name, mod in sys.modules.items():
> if name != 'encodings':
> mod.__dict__["__blob__"] = Blob(nam
Richard Oudkerk added the comment:
> You might want to open a prompt and look at gc.get_referrers() for
> encodings.mbcs.__dict__ (or another of those modules).
>>> gc.get_referrers(sys.modules['encodings.mbcs'].__dict__)
[, , , ]
>>> gc.get_referrers(sys.mo
Richard Oudkerk added the comment:
> I get different numbers from you. If I run "./python -v -c pass", most
> modules in the "wiping" phase are C extension modules, which is expected.
> Pretty much every pure Python module ends up garbage collected before
>
Richard Oudkerk added the comment:
> Also, do note that purge/gc after wiping can still be a regular
> gc pass unless the module has been wiped. The gc could be triggered
> by another module being wiped.
For me, the modules which die naturally after purging begins are
#
Richard Oudkerk added the comment:
Yes, I agree the patch is ok.
It would be would be much simpler to keep track of the module dicts if
they were weakrefable. Alternatively, at shutdown a weakrefable object
with a reference to the module dict could be inserted in to each module
dict. We
Richard Oudkerk added the comment:
Firstly, list2cmdline() takes a list as its argument, not a string:
>>> import subprocess
>>> print subprocess.list2cmdline([r'\"1|2\"'])
\\\"1|2\\\"
But the problem with passing arguments to a batch fi
Richard Oudkerk added the comment:
> I think you're missing the point. The implementation is wrong as it
> does not do what documentation says which is "A double quotation mark
> preceded by a backslash is interpreted as a literal double quotation
> mark."
That
Changes by Richard Oudkerk :
Added file: http://bugs.python.org/file31186/b3620777f54c.diff
___
Python tracker
<http://bugs.python.org/issue8713>
___
___
Python-bug
Richard Oudkerk added the comment:
I have done quite a bit of refactoring and added some extra tests.
When I try using the forkserver start method on the OSX Tiger buildbot (the
only OSX one available) I get errors. I have disabled the tests for OSX, but
it seemed to be working before
Richard Oudkerk added the comment:
> IMHO it just doesn't make sense passing 0.0 as a timeout value.
I have written lots of code that looks like
timeout = max(deadline - time.time(), 0)
some_function(..., timeout=timeout)
This makes perfect sense. Working code should not b
Richard Oudkerk added the comment:
> Richard, can you say what failed on the OS X 10.4 (Tiger) buildbot?
There seems to be a problem which depends on the order in which you run
the test, and it happens on Linux also. For example if I do
./python -m test
Changes by Richard Oudkerk :
Added file: http://bugs.python.org/file31214/c7aa0005f231.diff
___
Python tracker
<http://bugs.python.org/issue8713>
___
___
Python-bug
Richard Oudkerk added the comment:
The forkserver process is now started using _posixsubprocess.fork_exec(). This
should fix the order dependent problem mentioned before.
Also the forkserver tests are now reenabled on OSX.
--
___
Python tracker
Changes by Richard Oudkerk :
Added file: http://bugs.python.org/file31282/4fc7c72b1c5d.diff
___
Python tracker
<http://bugs.python.org/issue8713>
___
___
Python-bug
Richard Oudkerk added the comment:
I have added documentation now so I think it is ready to merge (except for a
change to Makefile).
--
___
Python tracker
<http://bugs.python.org/issue8
Richard Oudkerk added the comment:
> Good for me. This is a very nice addition!
Thanks.
I do see a couple of failed assertions on Windows which presumably happen in a
child process because they do not cause a failure:
Assertion failed: !collecting, file ..\Modules\gcmodule.c, line 1
Richard Oudkerk added the comment:
Do you mean you want to use a pure python implementation on Unix?
Then you would have to deal with AF_UNIX (which is the default family for
socketpair() currently). A pure python implementation which deals with AF_UNIX
would have to temporarily create a
Richard Oudkerk added the comment:
> I could submit the part that makes it possible to customize the picklers
> of multiprocessing.pool.Pool instance to the standard library if people
> are interested.
2.7 and 3.3 are in bugfix mode now, so they will not change.
In 3.3 you can do
Richard Oudkerk added the comment:
Adding the line
features[0][0]
to the end of main() produces a segfault for me on Linux.
The FAQ for sqlite3 says that
Under Unix, you should not carry an open SQLite database across a
fork() system call into the child process. Problems will
Richard Oudkerk added the comment:
On 21/08/2013 3:46pm, Charles-François Natali wrote:
> Another, probably cleaner way would be to finally add the atfork()
> module (issue #16500), and register this reseed hook (which could then
> be implemented in ssl.py).
Wouldn't that still s
Changes by Richard Oudkerk :
--
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk added the comment:
Hopefully this is fixed now.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python
Richard Oudkerk added the comment:
Yes I will remove it. I was planning on doing so when PEP 446 was implemented.
--
___
Python tracker
<http://bugs.python.org/issue18
Richard Oudkerk added the comment:
The PPC64 buildbot is still failing intermittently.
--
resolution: invalid ->
status: closed -> open
___
Python tracker
<http://bugs.python.org/i
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk added the comment:
It looks like the main process keeps getting killed by SIGUSR1. Don't know why.
--
___
Python tracker
<http://bugs.python.org/is
Richard Oudkerk added the comment:
> If the _killer process takes too long to start, it won't send SIGUSR1
> before the p process returns...
Thanks!
--
___
Python tracker
<http://bugs.python.
Richard Oudkerk added the comment:
It should be fixed now so I will close.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk added the comment:
Try using Popen(..., bufsize=0).
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue18868>
___
___
Python-bugs-list m
Richard Oudkerk added the comment:
> I've seen test_multiprocessing_forkserver giving warnings too, while
> running the whole test suite, but can't reproduce them while running it
> alone. The warnings seems quite similar though, so a single fix might
> resolve the prob
Richard Oudkerk added the comment:
On 05/09/2013 9:28am, Charles-François Natali wrote:
> As a side note, in the general case, there's more than a performance
> optimization: the problem with unregister() + register() vs a real
> modify (e.g. EPOLL_CTL_MOD) is that it'
Richard Oudkerk added the comment:
LGTM.
But I would move "import selectors" in multiprocessing.connection to just
before the definition of wait() for Unix. It is not needed on Windows and
unnecessary imports slow down start up of new
Richard Oudkerk added the comment:
I remember wondering at one time why EPOLLNVAL did not exist, and realizing
that closed fds are just silently unregistered by epoll().
I guess the issue is that some of the selectors indicate a bad fd on
registration, and others do it when polled
Richard Oudkerk added the comment:
With the current patch __repr__() will fail if the untransformed key is
unhashable:
>>> d = collections.transformdict(id)
>>> L = [1,2,3]
>>> d[L] = None
>>> d.keys()
Traceback (most recent call last):
File "&quo
Richard Oudkerk added the comment:
With your patch, I think if you call get_start_method() without later calling
set_start_method() then the helper process(es) will never be started.
With the current code, popen.Popen() automatically starts the helper processes
if they have not already been
Richard Oudkerk added the comment:
> In my patched version, the private popen.get_start_method gets a kwarg
> set_if_needed=True. popen.Popen calls that as before, so its behavior
> should not change, while the public get_start_method sets the kwarg to
> False.
Richard Oudkerk added the comment:
By "context" I did not really mean a context manager. I just meant an object
(possibly a singleton or module) which implements the same interface as
multiprocessing.
(However, it may be a good idea to also make it a context manager whose
__enter_
Richard Oudkerk 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
Richard Oudkerk 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
Richard Oudkerk 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 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
___
Python
Richard Oudkerk 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/file25361
Richard Oudkerk added the comment:
Warning added to patch.
--
Added file: http://bugs.python.org/file25362/mp_resource_sharer_stop.patch
___
Python tracker
<http://bugs.python.org/issue14
Richard Oudkerk 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
<http://bugs.python.org/issue14
Richard Oudkerk 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 n
Richard Oudkerk 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 threads, so it should
Richard Oudkerk 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:
...
Richard Oudkerk 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 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
Of these the only ones
Richard Oudkerk 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 STRUNCATE
Richard Oudkerk 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 am no
Richard Oudkerk 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
<http://bugs.python.org/issue9
Richard Oudkerk 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 ug
Richard Oudkerk 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 o
Richard Oudkerk 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 err
Richard Oudkerk 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
<http://b
Richard Oudkerk 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
Richard Oudkerk 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 t
Richard Oudkerk 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
<http://bugs
Richard Oudkerk 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 has
New submission from Richard Oudkerk :
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 multiprocessing.connection.wait
Richard Oudkerk 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 o
Changes by Richard Oudkerk :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue14725>
___
___
Python-bugs-list
Richard Oudkerk 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
<http://bugs.py
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk 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...
Fail
Richard Oudkerk 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 th
Richard Oudkerk 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 rename
openssl
Richard West added the comment:
I also had an ImportError on _struct module during 'make install' when building
2.7.3 from source configured with --enable-shared. My solution, which *seems*
to have worked, is simple:
$ make -i install
$ make install
My guess is that the p
Richard Oudkerk 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
not be possible
Changes by Richard Oudkerk :
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue14881>
___
___
Python-bugs-list mailing list
Unsubscribe:
Richard Oudkerk 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.
* I
201 - 300 of 1064 matches
Mail list logo
