[issue27889] ctypes interfers with signal handling
Andre Merzky
report at bugs.python.org
Tue Sep 6 01:29:59 EDT 2016
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 `finally` clause when the exception arises.
The problem though is different: please feel free to set the sleep in the `try` block to `sleep(100)` -- and unless the thread creation and startup takes 99 seconds, you should *not* run into that race, the problem however persists:
-------------------------------------------------------
merzky at thinkie:~ $ grep -C 2 sleep bug.py
def sub(pid):
time.sleep(1)
os.kill(pid, signal.SIGUSR2)
--
t = mt.Thread(target=sub, args=[os.getpid()])
t.start()
time.sleep(100)
except Exception as e:
print 'except: %s' % e
merzky at thinkie:~ $ while true; do i=$((i+1)); echo -n "$i: "; python bug.py || break; done
1: except: caught sigusr2
2: except: caught sigusr2
3: except: caught sigusr2
4: Traceback (most recent call last):
File "bug.py", line 30, in <module>
print 'unexcepted'
File "bug.py", line 14, in sigusr2_handler
raise RuntimeError('caught sigusr2')
RuntimeError: caught sigusr2
------------------------------------------------------
In this case, the begaviour does depend on `ctypes` -- or at least I have not seen that problem without `ctypes` being used.
Thanks, Andre.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27889>
_______________________________________
More information about the Python-bugs-list
mailing list