New submission from Martin Ritter <mce.rit...@gmail.com>:
Hi,
I tried to use
subprocess.run(..., stdout=subprocess.PIPE, timeout=N)
to run some test scripts with a given timeout.
This works as expected with simple scripts. However if the script itself
creates other children
Martin Ritter added the comment:
Dear Davin,
Thanks for the input, I was perfectly aware that the "solution" I proposed is
not realistic. But the feedback that multiprocessing is using threads
internally is useful as I can quickly abandon the idea to do something like the
check
Martin Ritter added the comment:
I agree that this is error prone and can not be fixed reliably on the python
side. However, python makes it very easy to mix these two, a user might not
even notice it if a function he calls uses fork and thus just use a
ThreadPoolExecutor() because it's
Martin Ritter added the comment:
For me compiling 3.5.2 on GCC 5.2.0 fails when I supply --with-cxx-main=g++
with the same "error: ‘_Atomic’ does not name a type" messages.
I'm guessing that --with-cxx-main is probably outdated(?) but at least it
worked with 3.5.0
--
nos
Martin Ritter added the comment:
I attached a gdb backtrace of one of the child processes
--
Added file: http://bugs.python.org/file43589/test_threadfork_backtrace.txt
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Martin Ritter:
When creating a multiprocessing.Process in a threaded environment I get
deadlocks waiting, I guess waiting for the lock to flush the output.
I attached a minimal example of the problem which hangs for me starting with 4
threads.
--
files
