bug-guile
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]