Path: ...!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: John Levine <johnl@taugh.com>
Newsgroups: comp.arch
Subject: Re: Continuations
Date: Sun, 14 Jul 2024 22:29:05 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <v71jfh$jko$1@gal.iecc.com>
References: <v6tbki$3g9rg$1@dont-email.me> <4j389jlb44kuhi3o5igf8ucnks3q9m3lc8@4ax.com> <v714in$1foh$2@gal.iecc.com> <lfims1Fl57mU1@mid.individual.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 14 Jul 2024 22:29:05 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
	logging-data="20120"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <v6tbki$3g9rg$1@dont-email.me> <4j389jlb44kuhi3o5igf8ucnks3q9m3lc8@4ax.com> <v714in$1foh$2@gal.iecc.com> <lfims1Fl57mU1@mid.individual.net>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
Bytes: 3276
Lines: 44

According to Niklas Holsti  <niklas.holsti@tidorum.invalid>:
>> This programming style is very old. The SAGE air defense system used
>> it in the 1950s, and SABRE copied it in the early 1960s. The software
>> was oranizaed into routines each of which took some input, did
>> something with it, perhaps scheduled other I/O operations, and then
>> explicitly saved its state and returned to the dispatcher. 
>
>I think that looks more like a multi-tasking system with 
>run-to-completion, non-preemptive (small) tasks, considering each 
>"routine" as a task and assuming that each routine started with 
>recovering its saved context.

Right, that saved context is the continuation.  Like I said, the tools
these days take care of a lot of the drudge work, e.g. node.js.

>The main difference to present-day multi-tasking systems is then that 
>the context-saving and -restoring was implemented separately and 
>specifically in each task, and not in a shared "task switch" function.

Not really.  The context is specific to each routine.  It's not like
time-slicing, it's do as much work as you can and then block for I/O.
The context you save depends on what you're doing.

>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.



-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly