<div dir="ltr"><div>Okay, the issue was trickier than I thought - I implemented the fix, with <span style="font-size:12.8000001907349px">[EOF-ERROR-VALUE]</span><span style="font-size:12.8000001907349px">  defined as </span>___ERRNO_ERR(EBADF), which should be a fair enough behavior, but Gambit did not terminate.</div><div><br></div><div>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.).</div><div><br></div><div>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?</div><div><br></div><div>I guess that is the most reasonable behavior.</div><div><br></div><div>And then, how will the REPL learn to know that that is the case.</div><div><br></div><div>Clarifying the nature of and resolving this bug is not complicated, but, it is slightly more involved than I thought would be necessary.</div><div><br></div><div>Any clarifications on your take on the above or pointers to how solve would be much appreciated.<br><br></div><div><br></div><div>(</div><div>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 <a href="https://github.com/feeley/gambit/issues/104">https://github.com/feeley/gambit/issues/104</a> .</div><div>)</div><div><br></div><div>Mikael</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-25 8:13 GMT+05:30 Mikael <span dir="ltr"><<a href="mailto:mikael.rcv@gmail.com" target="_blank">mikael.rcv@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Dear Marc,<br></div><div><br></div><div>I've tracked down a TTY IO bug here, <a href="https://github.com/feeley/gambit/issues/100" target="_blank">https://github.com/feeley/gambit/issues/100</a> .</div><div><br></div><div>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.</div><div><br></div><div>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 ();".</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Thanks,</div><div>Mikael</div><div><br></div></div>
</blockquote></div><br></div>