ITS approach to system calls
Mon, 9 Jun 1997 18:20:39 +0200 (MET DST)
[Cross-posted on LispOS and Tunes-LLL]
>: ~jrm on LispOS (19970531)
> I have posted Alan Bawden's excellent paper on how ITS handled
> system calls. [...] http://www.eval-apply.com/LispOS/pclsr.htm
Yeah, funny how I reinvented this wheel in the Tunes LLL,
with the generic interrupt-recovery mechanism.
Only the Tunes way is more generic and higher-level than ITS:
because every thread may be running at some abstract level of computation,
with an abstract instruction set that needn't be
the raw CPU hardware with magic OS instructions.
Instead, most thread run with some high-level of consistency
(Kernel Lisp or Common Lisp, whatever), with high-level invariants
(not only PC identity, but also stable GC-compliant state, etc).
When inspecting or debugging a Lisp program at source level,
you'll see the high-level operations and values.
Nonetheless, the implementation may use a lot of optimized
assembly code everywhere: by use of reflection,
where meta-objects can locally break objects' invariants,
as long as the abstract invariant is restored
whenever abstract observation takes place.
Every thread of control will maintain the illusion
of the virtual machine choosen, not more, not less.
> As a side note, the Lisp Machine handled interrupted system
> calls by saving the state of the microcode in the stack group
> that was interrupted. This has a few negative consequences:
> 1. It is insecure (security was never an issue on a Lisp Machine).
All CPUs allow that data be saved in special
areas during interrupts, even if this means buffering some of it
temporarily in the "current stack".
If we use continuations (be them linear), instead of stack group,
this becomes a non-issue (or rather an orthogonal memory-management issue).
> 2. The microcode needed to be careful about dangling pointers
> in machine regs if it did anything that might trigger an interrupt.
> I don't think the Symbolics machines had this problem, but it
> would cause an occaisonal crash on an LMI machine.
This in no way is related to stack groups.
The very fact that we have a high-level abstract machine with some invariants
(like, memory/register layout compliance to the GC) forces us to be careful
wrt interrupts. Any invariant should be enforced at any abstract place of
the program. This might mean that critical sections be enclosed in
(with-interrupts-recoverer thunk recoverthunk)
== Fare' -- email@example.com -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
TUNES is a Useful, Not Expedient System