Thu, 10 Apr 1997 10:23:24 -0500
Let us view a different kind of problem. Suppose we
are running machinery, turn on an engine do a process
turn off the engine. If the process aborts or is
aborted the engine must turn off.
Every control block must be given the opportunity
to clean up after itself. Now we add multi tasking,
one way is to have a stack for every task but another
is continuations. Execution frames are objects the
places where they clean up after themselves are
finalizers. This has several advantages over the stack
model, tasks take fewer resources and start faster
and there are other kinds of flexibility.
You start a task by building an execution frame,
storing the continuation on a task list and starting
the new frame. If it delays another task is taken
off the task list to run while its continuation is
put on the task list.
If a task is aborted any finalizers connected with
its execution frames must be executed. But in what
order? Most conventional is stack unrolling but we
are shutting down engines etc and that may be a
very bad order. There must be a way to determine
Further shutdown must be prompt. I don't mean as fast
as possible because that runs into the halting problem
but the billion dollar lottery that pays off a dollar
a year isn't acceptable either.
Assuming these continuations are full scale objects
that can take messages post finalized objects are
now possible and useful. I want to ask the execution
frame that ran the conveyer how many widgets it delivered
but I don't want to ask until it has shut down. Its
post finalized form is now more useful than its pre
finalized form but only to a some consumers. We can
still interrogate these post finalized objects for
various states and counts. They are no less valid than
prefinalized objects they simply have a different state.
Charles Fiterman Geodesic Systems
414 North Orleans Suite 410 Phone 312 832 1221 x223
Chicago IL 60610-4418 FAX 312 832 1230
A computer language without garbage collection
is like a city without garbage collection.