Question for os_tty.c:1063 to solve closed-TTY input Gambit zombie+CPU hogging bug
Dear Marc, I've tracked down a TTY IO bug here, https://github.com/feeley/gambit/issues/100 . On os_tty.c:1062 which is "if ((n = read (d->fd, buf, len)) < 0)", the < should be changed to <= because a 0 return value *always* means EOF in the sense that the TTY has been closed, see issue for more info. Then, os_tty.c:1063 needs to be updated from: "return err_code_from_errno ();" to something like "return n == 0 ? ___FIX([EOF-ERROR-VALUE]) : err_code_from_errno ();". The purpose of ___FIX([EOF-ERROR-VALUE]) is to signal to the underlying logic, which is the Gambit C VTBL IO abstraction, that the TTY is closed so that the REPL's input will be #!eof and Gambit supposedly will shut down, instead of repeating the read() infinitely, as is the case now. You know best which value is suitable in the place of [EOF-ERROR-VALUE] here - can you please suggest so a patch can be produced? Thanks, Mikael
Okay, the issue was trickier than I thought - I implemented the fix, with [EOF-ERROR-VALUE] defined as ___ERRNO_ERR(EBADF), which should be a fair enough behavior, but Gambit did not terminate. It seems that Gambit ordinarily only terminates if it gets a SIGHUP signal from the OS. So here I have shown examples of when the terminal shuts down without the OS sending any SIGHUP: It's as simple as starting Gambit (gsc), putting it in the background (press ctrl+z + run "bg"), and closing the terminal (exit, alt+f4 etc.). So the next question here now then is, if Gambit is running a REPL and it detects that the terminal is permanently closed, should not Gambit then shut down automatically? I guess that is the most reasonable behavior. And then, how will the REPL learn to know that that is the case. Clarifying the nature of and resolving this bug is not complicated, but, it is slightly more involved than I thought would be necessary. Any clarifications on your take on the above or pointers to how solve would be much appreciated. ( Second, I found a related bug - at least Linux seems to have some exotic terminal handling for when you start "gsc" and press "ctrl+z", where it responds weirdly to read() when the terminal is detached, it seems like it's making a noop of the read() call and then sending a SIGTTIN signal for some purpose - anyhow, in the OS' eyes, Gambit does not respond properly to that signal, and therefore he OS keeps re-sending the same signal in infinity. Documented at https://github.com/feeley/gambit/issues/104 . ) Mikael 2015-01-25 8:13 GMT+05:30 Mikael <mikael.rcv@gmail.com>:
Dear Marc,
I've tracked down a TTY IO bug here, https://github.com/feeley/gambit/issues/100 .
On os_tty.c:1062 which is "if ((n = read (d->fd, buf, len)) < 0)", the < should be changed to <= because a 0 return value *always* means EOF in the sense that the TTY has been closed, see issue for more info.
Then, os_tty.c:1063 needs to be updated from: "return err_code_from_errno ();" to something like "return n == 0 ? ___FIX([EOF-ERROR-VALUE]) : err_code_from_errno ();".
The purpose of ___FIX([EOF-ERROR-VALUE]) is to signal to the underlying logic, which is the Gambit C VTBL IO abstraction, that the TTY is closed so that the REPL's input will be #!eof and Gambit supposedly will shut down, instead of repeating the read() infinitely, as is the case now.
You know best which value is suitable in the place of [EOF-ERROR-VALUE] here - can you please suggest so a patch can be produced?
Thanks, Mikael
participants (1)
-
Mikael