Vilnis Termanis added the comment:
Apologies, my mistake - it does indeed work with 3.9 & 3.10. Feel free to close.
--
resolution: -> works for me
status: open -> pending
versions: +Python 3.8
___
Python tracker
<https://bu
Vilnis Termanis added the comment:
If you un-comment the print_exc() call, you'll see that it still fails - for
queue.Queue:
Manager failure (for Queue)
Traceback (most recent call last):
File "fish.py", line 74, in main
add_type_in_own_process(mgr, type_name)
File "fi
Changes by Vilnis Termanis <vilnis.terma...@googlemail.com>:
--
type: crash -> behavior
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by Vilnis Termanis <vilnis.terma...@googlemail.com>:
--
type: -> crash
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
New submission from Vilnis Termanis:
Accessing some Manager types (e.g. Lock) through a list, dict or Namespace
proxy is not possible if both the mutable container (e.g. list) and contained
type instance (e.g. Lock) have been created in the same process.
Symptoms:
In accessing process
Vilnis Termanis added the comment:
I've added a regression test for the proposed patch along the lines of the
example script (i.e. fails before and passes with patch). Apologies if the test
is a bit clumsy - maybe there is a more elegant way?
--
Added file: http://bugs.python.org
Vilnis Termanis added the comment:
I realise that having type bug type of "performance" means it's less likely to
be looked at than if I had marked is as "behaviour" or "resource usage" (which
would not be completely unfair, I think).
Also, the patch shoul
Vilnis Termanis added the comment:
A few additional notes:
1) On an AMD E-450 under Ubuntu 14.04 x64 with a current in-development build,
when running condition_test.py, Condition.notify_all() takes (measure using
time.clock) 0.0003 with the patch and 0.3219 without it. Additionally
Changes by Vilnis Termanis <vilnis.terma...@googlemail.com>:
Added file: http://bugs.python.org/file40854/condition_test.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Vilnis Termanis:
multiprocessing's Condition uses a couple of semaphores to keep track of
processes which are sleeping and have woken up whilst waiting for the
condition. These counters however are only ever decremented in the
notify(_all) functions, via a loop which results
Vilnis Termanis vilnis.terma...@googlemail.com added the comment:
Please find attached an updated patch (including unit test) for the
release27-maint branch. I've run the test_multiprocessing suite against svn
revision 86129 of said branch.
--
Added file: http://bugs.python.org
Vilnis Termanis vilnis.terma...@googlemail.com added the comment:
The idea is to pickle the object immediately (i.e. when added) instead of when
requested (dequeued). This means that any operations (even deletion) performed
on the original object do not make changes to the item in the queue
Changes by Vilnis Termanis vilnis.terma...@googlemail.com:
--
versions: +Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8037
Vilnis Termanis vilnis.terma...@googlemail.com added the comment:
I tried to reproduce / narrow-down the cause of this with a debug build in a VM
but couldn't reproduce the behaviour (neither with debug nor with standard
2.6.4 binary). I have to conclude that there is something perculiar
Changes by Vilnis Termanis vilnis.terma...@googlemail.com:
Removed file: http://bugs.python.org/file16473/queues.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8037
Vilnis Termanis vilnis.terma...@googlemail.com added the comment:
Updated patch to include new test (now against release26-maint branch).
Verified test_multiprocessing suite passes before (apart from new test) after
change. (Tested under Ubuntu 9.10 64-bit)
--
Added file: http
Changes by Vilnis Termanis vilnis.terma...@googlemail.com:
Removed file: http://bugs.python.org/file16415/pickle_suggestion_v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8037
Vilnis Termanis vilnis.terma...@googlemail.com added the comment:
Updated patch to include new test (now against release26-maint branch).
Verified test_multiprocessing suite passes before (apart from new test) after
change. (Tested under Ubuntu 9.10 64-bit)
--
Added file: http
Changes by Vilnis Termanis vilnis.terma...@googlemail.com:
Removed file: http://bugs.python.org/file16472/queues.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8037
Changes by Vilnis Termanis vilnis.terma...@googlemail.com:
Added file: http://bugs.python.org/file16475/queues.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8037
New submission from Vilnis Termanis vilnis.terma...@googlemail.com:
Affects Win32 only (tested under Ubuntu 9.10-64 and XP-32 with v2.6.4). If
script output is piped, child processes created via multiprocessing.Process
cannot write to stdout. Also, trying to call stdout.flush() in child
Vilnis Termanis vilnis.terma...@googlemail.com added the comment:
I couldn't see the wood for the trees:
If put() is thread-blocking, multiprocessing.Queue is reduced to the same
functionality as multiprocessing.queues.SimpleQueue, if I'm not mistaken. So
maybe there should be a warning
Changes by Vilnis Termanis vilnis.terma...@googlemail.com:
Removed file: http://bugs.python.org/file16412/lock_suggestion.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8037
Changes by Vilnis Termanis vilnis.terma...@googlemail.com:
Removed file: http://bugs.python.org/file16409/queue_example.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8037
Changes by Vilnis Termanis vilnis.terma...@googlemail.com:
Added file: http://bugs.python.org/file16413/queue_example.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8037
Vilnis Termanis vilnis.terma...@googlemail.com added the comment:
Alternative suggestion (since SimpleQueue doesn't provide buffering):
Allow option to force immediate pickling of the object to be en-queued, i.e.
pickling when adding to internal buffer instead of as part of Connection.send
Vilnis Termanis vilnis.terma...@googlemail.com added the comment:
Performance comparison before/after suggested change (adding/removing 1000-item
list 1 times).
Inline
1.926 class 'multiprocessing.queues.Queue'
1.919 class 'queues_pickled.Queue'
1.907 class 'queues_pickled.Queue
Changes by Vilnis Termanis vilnis.terma...@googlemail.com:
Removed file: http://bugs.python.org/file16414/pickle_suggestion.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8037
Changes by Vilnis Termanis vilnis.terma...@googlemail.com:
Added file: http://bugs.python.org/file16416/queue_perf.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8037
New submission from Vilnis Termanis vilnis.terma...@googlemail.com:
If an object, which as been put() in the multiprocessing.Queue is changed
immediately after the put() call then changed version may be added to the queue
which I assume is not the expected behaviour:
from multiprocessing
Vilnis Termanis vilnis.terma...@googlemail.com added the comment:
More notes:
- Reason for non-atmoic behaviour is due to queue _feeder thread sending the
object after the put() method has already exited. Hence changing the object
straight after put() can result in the modified object being
Vilnis Termanis vilnis.terma...@googlemail.com added the comment:
Quick though (last one I promise):
Maybe put() could have an argument to indicate whether to be thread-blocking
(i.e. guaranteeing the object to be sent in its current state) or not. The
(current) non-thread-blocking mode
Vilnis Termanis vilnis.terma...@googlemail.com added the comment:
Hi Meador,
I apologise: I really shouldn't have called it a patch. It's just to show one
way that I've found fixes the problem (but presumably reduces performance in
other cases, hence the suggestion wait for feedback
33 matches
Mail list logo
