On Wed, Oct 30, 2019 at 2:17 PM Tapley, Mark B. via cctalk < cctalk@classiccmp.org> wrote:
> All, > my daughter is well aware of my affinity for old computers and software, > and, as usual, she pointed out that there’s an XKCD for that: > > https://xkcd.com/2221/ > > I found this remarkably accurate. > For the dps8 emulator, I wrote (for expediency) the I/O code to complete immediately. When the CPU executes an I/O instruction, the I/O is completed and the interrupt posted before the next instruction is executed. As the emulator was (at that point) single threaded, there was no performance reason to do otherwise, and delaying interrupt delivery was additional code that I didn't want to write and debug. The consensus in the Multics community was that this was *probably* OK; the interrupt structure was robust and the interrupt handling code well written, and should be able to cope. But everytime a runtime failure occured, the question popped up: is zero-latency I/O the issue? I ended up adding code to delay interrupt delivery as a run-time configuration option so that that possibility could be checked. The XKCD is dead on for me. I have had that conversation. -- Charles
