Arkady added the comment:
"documentation of thread safety"
I find it surprising that a module called "multiprocessing" has not a thread
safe API.
If this is inevitable, I guess that's the life. I expect nothing less that a
bold bright red font at the top of the do
Arkady added the comment:
I have switched to os.fork() I am doing something like this
https://gist.github.com/larytet/3ca9f9a32b1dc089a24cb7011455141f
--
___
Python tracker
<https://bugs.python.org/issue40
Arkady added the comment:
I have reproduced a similar memory leak in the multiprocessing
This is the trace:
913 memory blocks: 33232 Bytes: File "/usr/lib/python3.7/threading.py", line
890;self._bootstrap_inner(); File "/usr/lib/python3.7/threading.py"
Arkady added the comment:
There is a memory leak every time call to join() fails (is
https://bugs.python.org/issue37788 relevant?)
--
___
Python tracker
<https://bugs.python.org/issue40
Arkady added the comment:
A workaround is to synchronize the call to Process.start()
diff --git a/main.py b/main.py
index d09dc53..49d68f0 100644
--- a/main.py
+++ b/main.py
@@ -26,17 +26,24 @@ def load_cpu(deadline):
while time.time() - start < 0.2*deadline:
math.
Arkady added the comment:
Update. I have reproduced the problem in the code not calling Process.join() at
all. It require more time and more load, but eventually Process.start() crashes.
Posted a question on
https://stackoverflow.com/questions/62276345/call-to-pythons-mutliprocessing
Arkady added the comment:
Is there any news about?
This 50 lines sample reproduces the problem
https://github.com/larytet-py/multiprocess
Please let me know if more information is needed.
--
___
Python tracker
<https://bugs.python.org/issue40
Arkady added the comment:
The problem is likely in the call to multiprocessing.Process.join() with
timeout. If I use timeout=None the code works.
--
___
Python tracker
<https://bugs.python.org/issue40
New submission from Arkady M :
I am running an HTTP server (socketserver.ThreadingMixIn,
http.server.HTTPServer) in a Docker container (FROM ubuntu:19.10)
Occasionally I get an exception:
Exception happened during processing of request from ('172.17.0.1', 35756)
Traceback (most r
Changes by Arkady “KindDragon” Shapkin :
--
resolution: -> not a bug
___
Python tracker
<http://bugs.python.org/issue28899>
___
___
Python-bugs-list mai
Arkady “KindDragon” Shapkin added the comment:
That was my fault
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue28899>
___
___
Py
New submission from Arkady “KindDragon” Shapkin:
I installed Python 3.5.2 with PDB, but they can't be loaded.
If I try to load them manually Visual Studio displays message "A matching
symbol file was not found in this folder."
--
components: Windows
messages: 2826
Arkady “KindDragon” Shapkin added the comment:
At least Python 2.7 should return in locale.getpreferredencoding() encoding
--
nosy: +Arkady “KindDragon” Shapkin
___
Python tracker
<http://bugs.python.org/issue13
Arkady Koplyarov added the comment:
Well, I believe that in BinHex.__init__() I cannot just wrap the _writeinfo
call into a try-finally block, and close ofp in the finally.
I see that in the case of normal operation when the exception is not thrown,
the output file descriptor ofp is used in
Arkady Koplyarov added the comment:
The testcase provided shows up a resource leakage:
-
C:\_cpython\cpython>PCbuild\python_d.exe -m test.regrtest test_binhex
[1/1] test_binhex
C:\_cpython\cpython\lib\unittest\case.py:574: ResourceWarning: unclosed file
<_io.BufferedWrite
Arkady Koplyarov added the comment:
The testcase updated accordingly to Nick Coghlan's suggestion to use
assertRaises() since the testcase deals with an exception.
--
Added file: http://bugs.python.org/file21252/testcase_for_binhex_module_2.
New submission from Arkady Koplyarov :
Testcase for exception binhex.Error to increase test coverage.
--
components: Library (Lib), Tests
files: testcase_for_binhex_module.patch
keywords: patch
messages: 131159
nosy: arkady.koplyarov
priority: normal
severity: normal
status: open
title
17 matches
Mail list logo
