Re: [MIT-Scheme-devel] primitives, interrupts, allocation, and robustness

[Joe Marshall]

On Wed, Jun 15, 2011 at 10:39 PM, Taylor R Campbell <address@hidden> wrote:
>
> * Problem 1: Interrupted primitives
>
> I have two ideas for policies to solve this problem.
>
> (a) If a primitive performs a permanent side effect, it may not use
> any system call afterward that could ever conceivably block.
>
> (b) PCLSR: After each permanent side effect, a primitive must mark its
> activation record so that if restarted after backing out, it will pick
> up where it left off.  This might entail using bind_interpreter_state
> after each effect and unbind_interpreter_state before the primitive
> returns, or it might entail replacing the primitive apply frame on the
> stack.  This may require essentially rewriting a number of primitives
> in continuation-passing style.

Either way is going to require a case-by-case analysis of the primitives.

> * Problem 2: Heap allocation bookkeeping in primitives
>
> Whenever a primitive wants to allocate n words on the heap, it checks
> whether n words are available.  If not, it requests n words from the
> garbage collector and backs out to let the garbage collector run.  If
> the garbage collector frees n words, Scheme restarts the primitive;
> otherwise, Scheme aborts to the nearest REPL and tells you that it's
> out of memory.

Another solution is to simply punt:  if out of memory, don't try to GC,
just abort to nearest.  (There are good engineering reasons to do it
this way, actually.)

In my opinion it is well beyond time for MIT Scheme to have a modern
generational GC.


-- 
~jrm