[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: exit & dynamic wind
From: |
Neil Jerram |
Subject: |
Re: exit & dynamic wind |
Date: |
Wed, 30 Mar 2011 22:54:24 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Andy Wingo <address@hidden> writes:
> As for explanations... Catch and throw are implemented using fluids and
> prompt and abort. (A discussion of that is here:
> http://wingolog.org/archives/2010/02/14/sidelong-glimpses .) An abort
> can pass arguments to the prompt's abort handler. It does so by pushing
> those values and a number-of-values marker onto the Scheme stack, after
> the Scheme and dynamic stacks are unwound to the prompt. The prompt
> then needs to pop off those values and pass them to the handler.
>
> It so happens that this values-then-number-of-values convention is the
> same convention as is used for multiple-value returns -- so for compiled
> code what happens is that the compiler inlines the handler, and the VM
> just does a multiple-value bind on the values from the stack. (See
> truncate-values in the VM instruction docs.)
>
> That's what happens when `prompt' is compiled, as it is in eval.scm.
> But before eval.scm is compiled, we use eval.c, which also has to have
> support for prompt and abort; but it's necessarily a different
> mechanism. This commit fixed a bug in that mechanism: that instead of
> looking for the number-of-values marker (the exact integer that it was
> expecting) from the VM's stack, as unwound by the abort,
i.e. SCM_VM_DATA (vm), I presume
> it was looking
> for it at the VM's stack-pointer as seen when the prompt was created
> --
i.e. SCM_PROMPT_REGISTERS (prompt)
> which necessarily is below any values returned to the prompt's abort
> handler.
>
> We didn't see this issue before because compiling eval.scm did not cause
> a `throw'. Interesting, no? But since I changed the implementation of
> ensure-writable-dir to one that probably throws, we see this error.
>
> Any other error that caused a `throw' to a `catch' to occur before
> eval.scm was compiled probably caused this error in the past. I don't
> know if we had any reports of it; I wouldn't be surprised. In any case,
> a tricky bug, and a good one to have fixed.
>
> We do have prompt and abort tests for the VM implementation. We don't
> run them with the boot evaluator, because we can't, not after eval.scm
> is compiled -- and anyway, now compilation causes throws at times, so
> we'll pick up these issues from users if it comes back.
>
> Hope that explains things :)
It certainly does, thank you!
Neil