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 &qu
Changes by Vilnis Termanis :
--
type: crash -> behavior
___
Python tracker
<http://bugs.python.org/issue28422>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Vilnis Termanis :
--
type: -> crash
___
Python tracker
<http://bugs.python.org/issue28422>
___
___
Python-bugs-list mailing list
Unsubscrib
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.pytho
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
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 re
Changes by Vilnis Termanis :
Added file: http://bugs.python.org/file40854/condition_test.py
___
Python tracker
<http://bugs.python.org/issue25469>
___
___
Python-bug
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 the
in
Vilnis Termanis 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/file19472/patch_27maint
Vilnis Termanis 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, before it
has been dequeued
Changes by Vilnis Termanis :
--
versions: +Python 3.1
___
Python tracker
<http://bugs.python.org/issue8037>
___
___
Python-bugs-list mailing list
Unsubscribe:
Vilnis Termanis 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 with my
native Wi
Changes by Vilnis Termanis :
Added file: http://bugs.python.org/file16475/queues.diff
___
Python tracker
<http://bugs.python.org/issue8037>
___
___
Python-bugs-list mailin
Changes by Vilnis Termanis :
Removed file: http://bugs.python.org/file16472/queues.diff
___
Python tracker
<http://bugs.python.org/issue8037>
___
___
Python-bugs-list m
Vilnis Termanis 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://bugs.python.org/file1
Changes by Vilnis Termanis :
Removed file: http://bugs.python.org/file16415/pickle_suggestion_v2.patch
___
Python tracker
<http://bugs.python.org/issue8037>
___
___
Pytho
Vilnis Termanis 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://bugs.python.org/file1
Changes by Vilnis Termanis :
Removed file: http://bugs.python.org/file16473/queues.diff
___
Python tracker
<http://bugs.python.org/issue8037>
___
___
Python-bugs-list m
New submission from Vilnis Termanis :
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 processes
causes IOError.
Normal
Changes by Vilnis Termanis :
Added file: http://bugs.python.org/file16416/queue_perf.py
___
Python tracker
<http://bugs.python.org/issue8037>
___
___
Python-bugs-list m
Changes by Vilnis Termanis :
Removed file: http://bugs.python.org/file16414/pickle_suggestion.patch
___
Python tracker
<http://bugs.python.org/issue8037>
___
___
Pytho
Vilnis Termanis added the comment:
Performance comparison before/after suggested change (adding/removing 1000-item
list 1 times).
Inline
1.926
1.919
1.907 (bufferPickled = True)
2.138
2.379
2.304 (bufferPickled = True)
1.158
1.151
1.141 (bufferPickled = True
Vilnis Termanis 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()
in _feed thread. Does
Changes by Vilnis Termanis :
Added file: http://bugs.python.org/file16413/queue_example.py
___
Python tracker
<http://bugs.python.org/issue8037>
___
___
Python-bugs-list m
Changes by Vilnis Termanis :
Removed file: http://bugs.python.org/file16409/queue_example.py
___
Python tracker
<http://bugs.python.org/issue8037>
___
___
Python-bug
Changes by Vilnis Termanis :
Removed file: http://bugs.python.org/file16412/lock_suggestion.patch
___
Python tracker
<http://bugs.python.org/issue8037>
___
___
Python-bug
Vilnis Termanis 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 in the documentation
Vilnis Termanis 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 on the issu
Vilnis Termanis 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 will have better performance for
Vilnis Termanis 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 sent instead.
- Reproduced under
New submission from Vilnis Termanis :
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 import Queue
>
33 matches
Mail list logo
