TypeError/hang inside of Time.Sleep() when _thread.interrupt_main()

[AR-Kareem]

BPO	42730
Nosy	@eryksun
Superseder	bpo-23395: _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2021-03-17.21:45:01.486>
created_at = <Date 2020-12-24.17:29:09.501>
labels = ['type-bug']
title = 'TypeError/hang inside of Time.Sleep() when _thread.interrupt_main()'
updated_at = <Date 2021-03-17.21:45:01.486>
user = 'https://bugs.python.org/AR-Kareem'

bugs.python.org fields:

activity = <Date 2021-03-17.21:45:01.486>
actor = 'eryksun'
assignee = 'none'
closed = True
closed_date = <Date 2021-03-17.21:45:01.486>
closer = 'eryksun'
components = []
creation = <Date 2020-12-24.17:29:09.501>
creator = 'AR-Kareem'
dependencies = []
files = []
hgrepos = []
issue_num = 42730
keywords = []
message_count = 5.0
messages = ['383695', '383717', '383731', '383734', '388972']
nosy_count = 2.0
nosy_names = ['eryksun', 'AR-Kareem']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '23395'
type = 'behavior'
url = 'https://bugs.python.org/issue42730'
versions = ['Python 3.6']

[AR-Kareem]

I get a random TypeError exception thrown whenever I interrupt/kill a sleeping parent thread from a child thread but ONLY if the python script was invoked by a shell script with an & argument to make it run in the background. (this is in vanilla python)

This doesn't happen if invoked

(1) in command line
(2) in command line with &
(3) in shell script (without &)

Only in shell script with &.

Here is the python script named psc.py https://pastebin.com/raw/KZQptCMr
And here is the shell script named ssc.sh https://pastebin.com/raw/QQzs4Tpz that when ran will run the python script and cause the strange behaviour

Here is the output I'm seeing: -------------------

parent looping
child interrupting parent
why would I ever catch a TypeError?
Traceback (most recent call last):
  File "m.py", line 17, in <module>
    time.sleep(1)
TypeError: 'int' object is not callable

Here is the output I'm expecting: --------------------
parent looping
child interrupting parent
caught interruption raised from user or child thread :)

Another unexpected behaviour might be that python suddenly hangs.

Here is a stackoverflow question raised on this issue with discussion in the comments https://stackoverflow.com/questions/65440353/python-time-sleep1-raises-typeerror?noredirect=1#comment115697237_65440353

[eryksun]

When a process executes in the background from a non-interactive bash script, the initial handler for SIGINT is SIG_IGN (ignore). Prior to 3.7, _thread.interrupt_main() tries to trip SIGINT even when the C handler is set to SIG_IGN. But Python uses an integer constant for SIG_IGN (named IgnoreHandler in Modules/signalmodule.c), and trying to call it is a TypeError. This was fixed in 3.7+ to resolve bpo-23395. You've flagged this as an issue with 3.7, but the Stack Overflow question is for 3.6. If you're actually using 3.6 instead of 3.7, this issue should be closed as a duplicate.

To manually enable the normal KeyboardInterrupt exception, call signal.signal(signal.SIGINT, signal.default_int_handler).

[AR-Kareem]

My apologies, I meant to flag it as 3.6 instead of 3.7.

I see what's happening now, and thanks for providing the correct way to raise a KeyboardInterrupt.

Correctly flagged as 3.6 and closed.

Thanks.

[AR-Kareem]

Shouldn't the behaviour for _thread.interrupt_main() be always to interrupt the main thread.

I would expect that if a child thread uses _thread.interrupt_main() that the main thread be interrupted regardless of how the python script was invoked.

Wouldn't it be more reasonable to make _thread.interrupt_main() always raise a SIGINT? I'm not sure if this is technically considered a bug or not, but it seems that it's not functioning as intended even in Python 3.7

[eryksun]

Shouldn't the behaviour for _thread.interrupt_main() be always to
interrupt the main thread.

The underlying C API function, PyErr_SetInterrupt(), simulates SIGINT without actually sending the signal to the process via kill() or raise(), but the doc string of interrupt_main() doesn't explain this, or at least it didn't used to. bpo-43356 generalized _thread.interrupt_main() to support simulating any available signal, and hopefully the new doc string [1] clarifies the intent.

---

[1]

cpython/Modules/_threadmodule.c

Line 1194 in 9976834

PyDoc_STRVAR(interrupt_doc,