Richard Oudkerk added the comment:
Looks good to me.
(Any particular reason for ignoring AttributeError?)
--
___
Python tracker
<http://bugs.python.org/issue17
Richard Oudkerk added the comment:
The unit tests pass with the patch already (if we don't delete the "import imp"
line).
What attributes will be set by init_module_attrs()?
--
___
Python tracker
<http://bugs.pyt
Richard Oudkerk added the comment:
> BTW, I find .notify(N) not much useful, because the docs say it may wake
> more threads on a different implementation and also I can't never know
> whom am I waking.
The fact that more than N threads can wake up is not a problem if you are
Richard Oudkerk added the comment:
> This could solve the waiting problem for the "thread", but also may
> keep the other Condition objs waiting -- and that may not be problem
> because I'm already using .notify_all()
I don't understand what you mean.
> Prob
Richard Oudkerk added the comment:
> You cannot associate several conditions to the *inner lock*, because you
> don't have access to them (otherwise I wouldn't open this issue).
Condition.wait_for_any() would create a single inner lock and add it to the
_waiters list for each
Richard Oudkerk added the comment:
I can't say I know enough about batch files to understand much of the code, but
a few notes:
Windows XP does not have the command "where" which you use -- Python 3.4 will
still support XP.
Except perhaps for looping I would prefer to get ri
Richard Oudkerk added the comment:
> Can't this just be a Python script?
That would cause bootstrap issues for people who do not already have
python installed.
--
___
Python tracker
<http://bugs.python.org
Richard Oudkerk added the comment:
I am not to familiar with the signal handling machinery. (I only did
some refactoring to expose the event handle already used by time.sleep().)
The change looks reasonable, but I am also not sure how necessary it is
Richard Oudkerk added the comment:
The way to deal with this is to pass the write end of the pipe to the child
process so that the child process can explicitly close it -- there is no reason
to expect garbage collection to make this happen automatically.
You don't explain the diffe
Richard Oudkerk added the comment:
> The write end of that pipe goes out of scope and has no references in the
> child thread. Therefore, per my understanding, it should be garbage
> collected (in the child thread). Where am I wrong about this?
The function which starts the child p
Richard Oudkerk added the comment:
> So you're telling me that when I spawn a new child process, I have to
> deal with the entirety of my parent process's memory staying around
> forever?
With a copy-on-write implementation of fork() this quite likely to use less
memory th
Richard Oudkerk added the comment:
Presumably this is caused by the fact that Popen.__del__() ressurects self by
appending self to _active if the process is still alive.
On Windows this is unnecessary. On Unix it would be more sensible to just
append the *pid* to _active.
--
nosy
Richard Oudkerk added the comment:
> What I'm still trying to grasp is why Python explicitly leaves the
> parent processes info around in the child. It seems like there is
> no benefit (besides, perhaps, speed) and that this choice leads to
> non-intuitive behavior - like t
Richard Oudkerk added the comment:
On 03/06/2013 1:02am, spresse1 wrote:
> Whats really bugging me is that it remains open and I can't fetch a reference.
> If I could do either of these, I'd be happy.
> ...
> Perhaps I really want to be implementing with os.fork(). Si
Richard Oudkerk added the comment:
Forking as a side effect of importing a module is evil. I think raising a
RuntimeError is preferable to trying to make it Just Work.
But maybe one could do
void
_PyImport_ReInitLock(void)
{
if (import_lock != NULL
Richard Oudkerk added the comment:
On 03/06/2013 3:07pm, spresse1 wrote:
> I could reimplement the close_all_fds_except() call (in straight python, using
> os.closerange()). That seems like a reasonable solution, if a bit of a hack.
> However, given that pipes are exposed by multiproce
Richard Oudkerk added the comment:
Actually, you can use gc.get_referents(obj) which returns the direct children
of obj (and is presumably implemented using tp_traverse).
I will close.
--
resolution: -> rejected
stage: -> committed/rejected
status: open -&g
Richard Oudkerk added the comment:
> Furthermore, the complexity is rather bad: if T is the average number
> of waiting threads, an C the number of conditions being waited on, the
> wait is O(C) (appending to C wait queues) and wakeup is O(CT) (C
> removal from a T-length deque).
Richard Oudkerk added the comment:
> pid_t is HANDLE on Windows, which is a pointer.
I think this is wrong.
The signature of getpid() is
int _getpid(void);
so pid_t should be equivalent to int.
The complication is that the return values of spawn*() etc are process handles
(cast
Richard Oudkerk added the comment:
> @sbt: Would you like to have a strict separation between UNIX-like pid
> (pid_t) and Windows process identifier (HANDLE)?
Yes. And would I certainly like SIZEOF_PID_T == sizeof(pid_t) ;-)
Note that _winapi takes the policy of treating HANDLE
Richard Oudkerk added the comment:
I see _Py_PARSE_PID already exists but no others ...
--
___
Python tracker
<http://bugs.python.org/issue17931>
___
___
Pytho
Richard Oudkerk added the comment:
Attached is a patch that adds _Py_PARSE_INTPTR and _Py_PARSE_UINTPTR to
Include/longobject.h.
It also uses _Py_PARSE_INTPTR in Modules/posixmodule.c and PC/msvcrtmodule.c
and removes the definition for SIZEOF_PID.
--
Added file: http
Changes by Richard Oudkerk :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue17931>
___
___
Python-bugs-list mailing list
Unsubscri
Richard Oudkerk added the comment:
> PJE suggests importing atexit and registering finalize only when it's
> actually used. I guess this would be the easiest workaround.
Done.
--
status: open -> closed
___
Python tracker
<http:
New submission from Richard Oudkerk:
regrtest already tests for refcount leaks and memory allocation leaks. It can
also be made to check for file descriptor leaks (and perhaps also handles on
Windows).
Running with the attached patch makes it look like test_openpty, test_shutil
New submission from Richard Oudkerk:
If os.listdir() is used with an fd, but fdopendir() fails (e.g. if the the fd
is a normal file) then a duplicated fd is leaked.
This explains the leaks in test_shutil mentioned in #18174.
--
messages: 190875
nosy: sbt
priority: normal
severity
New submission from Richard Oudkerk:
Seems to be in error path of _PyImport_GetDynLoadWindows().
--
files: load_dynamic.patch
keywords: patch
messages: 190901
nosy: sbt
priority: normal
severity: normal
status: open
title: Refleak in test_imp on Windows
Added file: http
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> resource usage
versions: +Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python
Richard Oudkerk added the comment:
The test_shutil leak is caused by #17899. The others are fixed by
a7381fe515e8 and 46fe1bb0723c.
--
___
Python tracker
<http://bugs.python.org/issue18
Richard Oudkerk added the comment:
Updated version which adds checks for handle leaks on Windows.
--
Added file: http://bugs.python.org/file30561/fdleak.patch
___
Python tracker
<http://bugs.python.org/issue18
Changes by Richard Oudkerk :
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue9122>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Richard Oudkerk:
Currently when a module is garbage collected its dict is purged by replacing
all values except __builtins__ by None. This helps clear things at shutdown.
But this can cause problems if it occurs *before* shutdown: if we use a
function defined in a module
Richard Oudkerk added the comment:
Do you want something like
f.done() and not f.cancelled() and f.exception() is None
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue18
Changes by Richard Oudkerk :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue18214>
___
___
Python-bugs-list mailing list
Unsubscribe:
Richard Oudkerk added the comment:
On 15/06/2013 7:11pm, Antoine Pitrou wrote:
>> Usually garbage collection will end up clearing the module's dict anyway.
>
> This is not true, since global objects might have a __del__ and then hold
> the whole module dict alive throu
Richard Oudkerk added the comment:
I think if you use timeit then the code is wrapped inside a function before it
is compiled. This means that your code can mostly use faster local lookups
rather than global lookups.
--
nosy: +sbt
___
Python
Changes by Richard Oudkerk :
--
stage: committed/rejected ->
___
Python tracker
<http://bugs.python.org/issue18252>
___
___
Python-bugs-list mailing list
Un
Changes by Richard Oudkerk :
--
stage: -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue18252>
___
___
Python-bugs-list mailing list
Un
Changes by Richard Oudkerk :
--
keywords: +gsoc -patch
resolution: -> rejected
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk added the comment:
We don't do non-security updates on Python 2.6 anymore.
As a workaround you might be able to do something like
import sys, multiprocessing
sys.frozen = True# or multiprocessing.forking.WINEXE = True
...
if __name__ ==
Richard Oudkerk added the comment:
I just tried freezing the program
from multiprocessing import freeze_support,Manager
if __name__ == '__main__':
freeze_support()
m=Manager()
l = m.list([1,2,3])
l.append(4)
print(l)
print(repr(l))
using cx_F
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk added the comment:
See also #9573 and #15914.
--
___
Python tracker
<http://bugs.python.org/issue18122>
___
___
Python-bugs-list mailing list
Unsub
Changes by Richard Oudkerk :
--
resolution: -> works for me
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk added the comment:
This is a very similar issue to #17985.
While it may seem counter-intuitive, I don't see how it makes any difference.
Another thread/process might remove the item before you can get it.
I find it very difficult to imagine a real program where you can s
Richard Oudkerk added the comment:
Why would you use a multi-process queue to "pass messages from one part of the
program to another part, in the same process and thread"? Why not just use a
deque?
Is this something you actually did, or are you just trying to come up with a
Richard Oudkerk added the comment:
Apologies for being dense, but how would you actually use such a loader?
Would you need to install something in sys.meta_path/sys.path_hooks? Would it
make all imports lazy or only imports of specified modules?
--
nosy: +sbt
Richard Oudkerk added the comment:
Shouldn't the import lock be held to make it threadsafe?
--
___
Python tracker
<http://bugs.python.org/issue17621>
___
___
Richard Oudkerk added the comment:
> I did this to use the same abstraction that was used extensively for
> other purposes, instead of recreating the same abstraction with a deque
> as its basis.
So you wanted a FIFO queue and preferred the API of Queue to that of deque?
Well i
Richard Oudkerk added the comment:
unfinished_tasks is simply used as a counter. It is only accessed while
holding self._cond. If you get this error then I think the error text is
correct -- your progam calls task_done() to many times.
The proposed patch silences the sanity check by making
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk added the comment:
I was thinking about the line
self.__dict__.update(state)
overwriting new data with stale data.
--
___
Python tracker
<http://bugs.python.org/issue17
Richard Oudkerk added the comment:
> 1. "but should not cause any pratical difficulties" <-- you have a typo in
> 'pratical' there.
> 2. What exactly do you mean by "managed" queues in the new addition?
Woops. Fixed now see 860fc6a2bd21, 347647a1f
Changes by Richard Oudkerk :
--
assignee: -> docs@python
components: +Documentation -IO, Interpreter Core
nosy: +docs@python
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: behavior ->
___
Python
Richard Oudkerk added the comment:
This is really a documentation issue. The doc fix for #18277 covers this.
--
components: +Library (Lib) -Extension Modules
resolution: -> wont fix
stage: -> committed/rejected
status: open -> closed
type: -&
Richard Oudkerk added the comment:
I think in Python 3 makefile() returns a TextIOWrapper object by default. To
force the use of binary you need to specfiy the mode:
fileobj = ss.makefile(mode='rb')
--
nosy: +sbt
___
Python trac
Richard Oudkerk added the comment:
When modules are garbage collected the associated globals dict is purged -- see
#18214. This means that all values (except __builtins__) are replaced by None.
To work around this run_path() apparently returns a *copy* of the globals dict
which was created
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
1 - 100 of 737 matches
Mail list logo
