> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Wednesday, August 14, 2019 11:26 AM

>> I haven't done anything with line disciplines since the 1980s, but
>> the set, wait a bit, and reset paradigm of with-raw-mode
>> etc. wasn't the norm back then, a program like a version of EMACS
>> would set raw mode and stay in it, resulting in your having to
>> blindly type reset^J if it crashed without restoring the tty to
>> cooked mode.

> Could it be that unnecessary short trips to raw mode were avoided
> because you couldn't rely on hardware terminals responding fast enough?

I'm pretty sure no one thought of it, especially since we were all
starting out with a 64KiB code budget, enough for an ersatz EMACS
without user programmability, but it was tight, I think I can remember
blowing that budget while linking after making changes.

And I don't remember read having a timeout feature back then.  The
kernel was also under an extremely tight budget, the 2.x BSD releases
which added TCP/IP support had to do overlays.

There's three levels to the character input system:

https://en.wikipedia.org/wiki/Line_discipline

> A line discipline (LDISC) is a layer in the terminal subsystem in
> some Unix-like systems.  The terminal subsystem consists of three
> layers: the upper layer to provide the character device interface,
> the lower hardware driver to communicate with the hardware or pseudo
> terminal, and the middle line discipline to implement behavior
> common to terminal devices.

> The line discipline glues the low level device driver code with the
> high level generic interface routines (such as read(2), write(2) and
> ioctl(2)), and is responsible for implementing the semantics
> associated with the device.  The policy is separated from the device
> driver so that the same serial hardware driver can be used by
> devices that require different data handling.

It's the purely software line discipline that in cooked mode handles ^U
etc. without allowing read to return and task switch to your code.

>> Is there any chance characters a user will be typing will get
>> "stranded" in the finite interval between calls to with-raw-mode?

> You mean at the time the Unix TTY driver is configuring stuff to
> switch between the modes? No idea, but it's one call to tcsetattr(),
> which seems to map to one ioctl() call nowadays, so it's unlikely.

"Unlikely" makes me uncomfortable, this has the potential to be
annoyingly rare but very obnoxious.

> A realistic problem is that the Scheme thunk supplied to
> with-raw-mode will leave the extent of the with-raw-mode call before
> it has had the chance to restore cooked mode. with-raw-mode needs to
> have some unwind-protect-like behavior.

Providing that behavior is part of the with-raw-mode etc. spec, so
only a crash, (emergency-exit) or the like will potentially leave your
terminal in a messed up state.

- Harold