Re: Continuations

John Levine wrote:

According to Niklas Holsti  <niklas.holsti@tidorum.invalid>:

Could you explain a bit about the "dispatcher" and how it decided which
routine to execute next? Perhaps depending on which I/O had completed?

 As best I understand it, SABRE would receive a message from one of the
terminals and dispatch it to a routine based on the first few
characters that said what kind of request it was. The routine would
then do a bunch of work consisting of computing and disk I/O. Whenever
it scheduled a disk operation, it'd explicitly save its state and
return to the dispatcher. When the disk I/O was done, it'd schedule
the next part of the task which restored the state and continued.
Repeat until the task sends a reply to the terminal and is done.
 Airline reservation and credit card systems still work this way, and
have amazing transaction rates, like 1000 updates/sec to an individual
database record.

I used this approach (which I later learned was called coroutines) in my Dos terminal emulator: I wanted to process all characters as I received them, which meant that for any of the many, many escape sequences (for cursor positioning, font selection, foreground/background color etc) I needed to remember where I was.
Initially I just restored the read pointer to the beginning of the escape sequence, knowing I would be called again when one or more new characters had been received, so that I would always process the stream in complete units. However I soon realized that it was much cheaper to make the stream parser a separate routine which would yield when it ran out of inputs. I only needed a tiny bit on inline assembler to do the coroutine switching (mostly just a separate stack and IP, but no register contents).
The receiving routine would yield to the parser when the serial port buffer has some new data.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"