Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: Continuations
Date: Mon, 15 Jul 2024 11:56:32 +0200
Organization: A noiseless patient Spider
Lines: 40
Message-ID: <v72roh$l6tm$1@dont-email.me>
References: <v6tbki$3g9rg$1@dont-email.me>
 <4j389jlb44kuhi3o5igf8ucnks3q9m3lc8@4ax.com> <v714in$1foh$2@gal.iecc.com>
 <lfims1Fl57mU1@mid.individual.net> <v71jfh$jko$1@gal.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 15 Jul 2024 11:56:33 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8418b9450a97a5d989625748080a6c57";
	logging-data="695222"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/GY0v75wMe1UT79PzBa5rZbTJuHSkmmOP+EjDMr8Claw=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.2
Cancel-Lock: sha1:qmVljO1in7LbVMA/Er6q6WJWJck=
In-Reply-To: <v71jfh$jko$1@gal.iecc.com>
Bytes: 3245

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"