5 ms·
That's what happens when you read from a keyboard buffer. Since the buffer is not being read (and not cleared) until a prompt is in the screen, you can type whe
by whatever_dude 9y ago
That's what happens when you read from a keyboard buffer. Since the buffer is not being read (and not cleared) until a prompt is in the screen, you can type whether you want and it'll get dumped and processed whenever needed. Not that long ago really, that's how it worked in DOS and most other terminals.
- kijin 9y agoIt still works. I can ssh into a machine and start typing commands before the shell prompt appears. The commands will appear in the terminal once the connection is established and the shell is ready.
- chasd00 9y agoIsn't the keyboard buffer a part of the physical keyboard circuitry and interface? Hitting enter triggers an IRQ to flush the buffer, so if the CPU is too busy to handle the IRQ then things queue up until the CPU can get around to handling it. If that's the case, for this "feature" not to work would require a very low level architectural change to keyboards. (it's been many years since i've thought about this though)
- singingboyo 9y agoKeyboard buffers are decidedly not on the physical keyboard. The keyboard might have a very small one, but the IRQ is triggered on every input. The buffer in question is, for a tty, a driver-level buffer that holds on to the data until something reads it. If a command doesn't read it (which things like apt-get update don't) then it'll get read as the next command. Of course, most terminals these days are ptys accessed via emulators, so the buffer is actually part of the emulator, but the same idea applies.
- chasd00 9y agoah, the more you know :) I would have been shocked if i remembered all that correctly
- exikyut 9y agoFor some reason my brain still finds it important to remember that the BIOS keyboard buffer is 15 bytes by default, but that you could load tiny little devices drivers in CONFIG.SYS in MS-DOS to make it a whole 31 bytes.