I think we have two pretty deep problems in the way microcode
primitives work. Both fortunately and unfortunately, they manifest
very seldom in practice: fortunately because, well, most of the time
everything's OK; unfortunately because it makes them all the more
mysterious to diagnose and difficu
On Wed, Jun 15, 2011 at 10:39 PM, Taylor R Campbell 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)
>
> (a) If a primitive performs a permanent side effect, it may not use
> any system call afterward that could ever conceivably block. This
> means eliminating (or at least deprecating) complex primitives such as
> FILE-TOUCH and replacing them by Scheme code.
>
This is my favorite suggestion. I
Date: Fri, 17 Jun 2011 13:28:25 -0700
From: Joe Marshall
> 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 g
On Fri, Jun 17, 2011 at 1:56 PM, Taylor R Campbell wrote:
>
> 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.)
>
> Er... Then the GC would never run. Maybe you were referrin
