Andre Merzky added the comment:
This one might be related:
https://bugs.python.org/issue27889
--
nosy: +Andre Merzky
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Andre Merzky added the comment:
FWIW, a workaround seems to be a nested try/except clause:
try:
try:
do_lots_of_work()
except RuntimeError as e:
print 'signal handling worked'
except RuntimeError:
print 'signal handling delayed'
I did a stress test over 100k runs, and got
Andre Merzky added the comment:
I would appreciate any suggestion on how to avoid this problem -- otherwise it
seems that I can't reliably use signals in threaded contexts at all :(
Thanks, Andre.
--
___
Python tracker <rep...@bugs.python.
Andre Merzky added the comment:
I think we are on the same page then, thanks.
AFAIU, the C-level signal handler results in a flag being set, which is
evaluated at some later point in time[1], after a certain number of opcodes
have been executed. Could it be that those opcodes blindly
Andre Merzky added the comment:
Hi George,
> From these results, it appears there is no guarentee that the signal handler
> will run before the main thread continues execution at the time.sleep(500)
> line. This would explain why we advance to the else clause before the
&g
Andre Merzky added the comment:
Also thanks for the reply! :)
Interesting that our results differ: as said, my code stumbles over it rather
frequently, and I can't reproduce w/o ctypes activities. But indeed, the
latter might just reinforce a race condition which is present either way
Andre Merzky added the comment:
> The repro is tied to the time.sleep call in the try block. If I do
> time.sleep(1)
Yes - if both sleeps, the one in the `try` block and the one in the thread's
routine (`sub`) are equal, then you'll have the typical race, and you can well
be in the `f
Andre Merzky added the comment:
I also see the problem on 2.7.11, on MacOS, but with significantly lower
frequency. I can't tell if that is due to changes in Python, the different
architecture, or whatever...
$ python -V
Python 2.7.11
$ uname -a
Darwin cameo.local 14.4.0 Darwin Kernel
Andre Merzky added the comment:
I can confirm the same unexpected behavior for
Python 2.7.6 / Linux radical 4.2.0-25-generic #30~14.04.1-Ubuntu (2nd attempt)
Python 2.7.9 / Linux login1.stampede.tacc.utexas.edu 2.6.32-431.17.1.el6.x86_64
(32nd attempt)
Python 2.7.10 / Linux gordon-ln2
Andre Merzky added the comment:
Thanks for checking! I use:
$ uname -a
Linux thinkie 3.11-2-amd64 #1 SMP Debian 3.11.8-1 (2013-11-13) x86_64 GNU/Linux
$ python -V
Python 2.7.5+
Note that the problem does not occur on every run -- but in more than 50% of
the cases, for me. I am
New submission from Andre Merzky:
Summary: A thread uses signals to the MainThread to signal an abnormal
condition. The main thread is expected to get that signal, invoke the signal
handler, and raise an exception. In combination with 'ctypes' calls, that does
not happen.
Consider
Andre Merzky added the comment:
I can confirm that the patch provided by Victor addresses the problem. It
seems to be against the current HEAD -- is there a chance that this will be
backported to 2.7 (which is what I need to use)?
Thanks! Andre
Andre Merzky added the comment:
It seems you were right, that needed a DecRef indeed: the IncRef is already
called on construction. The DecRef for the result also needed fixing - an
updated patch is attached.
--
Added file: http://bugs.python.org/file43546/issue23395.2.patch
Andre Merzky added the comment:
thanks for looking into this! And also, thanks for the details in the original
bug report -- I found this by chance, after unsuccessfully banging my head
against this very problem for quite a while!
I am not sure if the DecRef needs to be called really
Andre Merzky added the comment:
Attached is a patch which seems to resolve the issue for me -- this now
triggers the expected `KeyboardInterrupt` in the main thread. For verification
one can run the unaltered code as provided by Thomas.
I would very much appreciate feedback, to make sure
Andre Merzky added the comment:
Thanks Thomas.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23395>
___
___
Python-bugs-list
Changes by Andre Merzky <andremer...@gmail.com>:
--
versions: +Python 2.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23395>
___
Andre Merzky added the comment:
Thanks for the PingBack, Thomas.
I am not very familiar with the Python community approach to bug reports, so
can someone comment if that is worth waiting for to get fixed, or is it that a
rather futile hope without providing a patch myself? I don't think I
Andre Merzky added the comment:
Did anything ever come of this? I also frequently stumble over that error --
but alas not in a debug setting, but on actual running code... :/
--
nosy: +Andre Merzky
___
Python tracker <rep...@bugs.python.org>
Andre Merzky added the comment:
This is patch is meant to be illustrative rather than functional (but it works
in the limited set of cases I tested).
--
keywords: +patch
Added file: http://bugs.python.org/file40448/subprocess.py.diff
___
Python
Andre Merzky added the comment:
Yes, I have a workaround (and even a clean solution) in my code. My interest
in this ticket is more academic than anything else :)
Thanks for the pointer to issue1731717. While I am not sure which 'comment at
the end' you exactly refer to, the whole
Changes by Andre Merzky <andremer...@gmail.com>:
Removed file: http://bugs.python.org/file40448/subprocess.py.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Andre Merzky <andremer...@gmail.com>:
Added file: http://bugs.python.org/file40449/subprocess.py.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Andre Merzky added the comment:
Hi again,
can I do anything to help moving this forward?
Thanks, Andre.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Andre Merzky added the comment:
Looking a little further, it seems indeed to be a problem with ignoring
SIGCHLD. The behavior has been introduced with [1] at [2] AFAICS, which is a
response to issue15756 [3]. IMHO, that issue should have been resolved with
raising an exception instead
Andre Merzky added the comment:
As mentioned in the PS, I understand that the approach might be questionable.
But (a) the attached test shows the problem also for watcher *processes*, not
threads, and (b) an error should be raised in unsupported uses, not a silent,
unexpected behavior which
New submission from Andre Merzky:
- create a class which is a subclass of multiprocessing.Process ('A')
- in its __init__ create new thread ('B') and share a queue with it
- in A's run() method, run 'C=subprocess.Popen(args=/bin/false)'
- push 'C' though the queue to 'B'
- call 'C.pull
27 matches
Mail list logo
