Interrupts are lost during readline PyOS_InputHook processing

[4fcc8b25-b139-4e19-9fcf-a88f676becf2]

BPO	3180
Nosy	@vstinner, @devdanzin
Files	input-hook.patch: Patch to implement interrupt handling input hook

^{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: ```python assignee = None closed_at = created_at = labels = ['extension-modules', 'type-feature'] title = 'Interrupts are lost during readline PyOS_InputHook processing' updated_at = user = 'https://bugs.python.org/Araneidae' ``` bugs.python.org fields: ```python activity = actor = 'Michiel.de.Hoon' assignee = 'none' closed = True closed_date = closer = 'vstinner' components = ['Extension Modules'] creation = creator = 'Araneidae' dependencies = [] files = ['10709'] hgrepos = [] issue_num = 3180 keywords = ['patch'] message_count = 7.0 messages = ['68638', '87719', '116638', '233530', '233977', '233981', '233998'] nosy_count = 4.0 nosy_names = ['vstinner', 'ajaksu2', 'Araneidae', 'Michiel.de.Hoon'] pr_nums = [] priority = 'normal' resolution = 'out of date' stage = 'patch review' status = 'closed' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue3180' versions = ['Python 2.7', 'Python 3.2'] ```

[4fcc8b25-b139-4e19-9fcf-a88f676becf2]

The (undocumented!) API for PyOS_InputHook has two defects which are addressed in the attached patch (at least when using the readline module): firstly the called hook currently has to guess that input will come on descriptor 0; secondly, any Ctrl-C interrupts encountered during the processing of the input hook are lost.

This loss of interrupts can be rather annoying. The attached patch addresses these problems by redefining the API to PyOS_InputHook as

    int PyOS_InputHook(int file_in);

where file_in is the descriptor to monitor (PyOS_InputHook need not return until file_in is ready to read), and the return value is non-zero if and only if processing was interrupted.

Testing for interruption is implemented in the HAVE_RL_CALLBACK and HAVE_SELECT branch of Modules/readline.c; other uses retain their original functionality (I believe!).

The attached patch was prepared against http://svn.python.org/projects/python/trunk , current at the time of writing.

[90baf024-6604-450d-8341-d796fe6858f3]

Michael, How does this interact with the fix from bpo-706406?

[83d2e70e-e599-4a04-b820-3814bbdb9bef]

I'm unsure as to whether this is a feature request or a behaviour problem, anyone? Regardless could a core dev take a look at the patch which involves changes to the API for PyOS_InputHook, see msg68638.

[vstinner]

I don't understand how to reproduce the issue, there is no unit test nor a description how to reproduce the issue.

I'm not aware of a bug where CTRL+c is simply ignored. CTRL+c is now well handled in Python 2.7, on Linux and Windows at least.

Since the bug is now 7 years old, I just close it as out of date, sorry.

[400312e9-0e94-409e-8ec0-4d798295c938]

As it happens, we just ran into the same bug. To reproduce this issue, run

>> from Tkinter import * >> Tk()

Then Ctrl-C will not generate a KeyboardInterrupt.

At first glance, the solution suggested by the original poster seems good. Can this issue by reopened? I'd be happy to take over this issue report and check the patch in more detail.

[vstinner]

This issue is now closed. Please open a new issue. You should mention your OS and the Python version at least.

[400312e9-0e94-409e-8ec0-4d798295c938]

I have opened a new bpo-23237 for this bug; please see http://bugs.python.org/issue23237