Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix a hang where ctrl-d can hang the next call to Readline #222

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

tpodowd
Copy link
Contributor

@tpodowd tpodowd commented Mar 6, 2023

When running the examples/readline-demo, you can enter the sleep command which causes the loop to sleep for 4 seconds before it calls Readline() again. If you press ctrl-d during the sleep, the program will hang.

Normally ctrl-d is mapped to CharDelete (rune:4), however termios manpage states that when not in raw mode the following is true:

VEOF (004, EOT, Ctrl-D) End-of-file character (EOF). More
precisely: this character causes the pending tty buffer to be sent
to the waiting user program without waiting for end-of-line. If
it is the first character of the line, the read(2) in the user
program returns 0, which signifies end-of-file. Recognized
when ICANON is set, and then not passed as input.

Between calls to Readline, the terminal is not in raw mode and thus read returns 0. Note that err=io.EOF is correctly unset.

Previously the terminal ioloop returned the 0 on the t.outchan which is being read by the operation ioloop. Unfortunately, 0 is also used to indicate EOF and thus the operation ioloop terminates which means that nobody will read from t.outchan any more and thus input processing stops and causes the hang.

The fix is simply to ignore 0 in the terminal and go on expecting characters.

When running the examples/readline-demo, you can enter the `sleep`
command which causes the loop to sleep for 4 seconds before it
calls Readline() again. If you press ctrl-d during the sleep,
the program will hang.

Normally ctrl-d is mapped to CharDelete (rune:4), however termios
manpage states that when not in raw mode the following is true:

> VEOF   (004,  EOT,  Ctrl-D)  End-of-file  character (EOF).  More
> precisely: this character causes the pending tty buffer to be sent
> to the waiting user program without waiting for end-of-line.  If
> it is the first character of the line, the read(2) in the user
> program  returns  0,  which  signifies  end-of-file. Recognized
> when ICANON is set, and then not passed as input.

Between calls to Readline, the terminal is not in raw mode and thus
read returns 0. Note that err=io.EOF is correctly unset.

Previously the terminal ioloop returned the 0 on the t.outchan
which is being read by the operation ioloop. Unfortunately, 0 is
also used to indicate EOF and thus the operation ioloop terminates
which means that nobody will read from t.outchan any more and
thus input processing stops and causes the hang.

The fix is simply to ignore 0 in the terminal and go on expecting
characters.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant