Re: Preemption, Persistence, and Mobility

[Dave Long <address@hidden>]

>    Can any one explain (or suggest good references on) how to use
> continuations to add fine grained preemptive threads to a light
> weight language?

1. use continuations to add coarse
   grained cooperative threads

2. add a (real/virtual) timeout to
   trigger forced context switches

>    Is it feasible/efficient to [use continuations to add fine grained
> preemptive threads] within the language's interpreter without invoking
> native OS services?

It is generally feasible, but may not
be efficient: how will you deal with
the case of a blocked native OS call?

>    Has anyone made continuations persistent, so a language user
> could *transparently* freeze a thread and thaw it during a subsequent
> execution run without having to manually tear it down to save its
> state out to disk and then read its state back in to rebuild it
> from scratch?

I'll bet dozens, if not hundreds,
of people have. [0][1][2]

Why the aversion to manual labor?
Often, an application is better
informed than its runtime system
about what part of its state is
essential. [3]

>     Assuming such a facility could be provided, how much more work
> would it be to make such a persistent thread mobile, so it could be
> transfered to a different network node?

That depends upon how similar the
different node is to the original
one.  If the continuation sits on
disk for any length of time, there
are many kinds of changes that can
affect the original node: reboots,
os upgrades, library upgrades, app
upgrades, even processor upgrades.

The more persistent a save-file is,
the more mobile it is likely to be.

-Dave

for general history, check out:
John C. Reynolds, "The Discoveries of Continuations"
Lisp & Symbolic Computation #6 233-247

[0] Swapping is the homespun version
of this scenario.

[1] Hoare recommends a dump command:
"Hints on Programming Language Design"
STAN-CS-73-403

[2] I believe I encountered grues for
the first time in an emulation of a
dumped FORTRAN program.

[3] Dijkstra mentions in EWD237 that
he is (as a subset of his general work
which views programs as instances of
their respective families) interested
in the problem of modifying a program
while it is working.  By EWD393 he has
discovered that running a program can
litter all manner of (in)decisions on
representations throughout its state.