[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: please help concerning specpdl

From: Davis Herring
Subject: Re: please help concerning specpdl
Date: Tue, 14 Dec 2010 16:14:50 -0800 (PST)
User-agent: SquirrelMail/1.4.8-5.el5_4.10.lanl3

> Why let-binding-variables are memorized exactly here and not elsewhere ?

Flet memorizes their old values on the stack; when it returns (or
otherwise is exited), the old values are copied back, so they can't be
needed beyond the lifetime of that stack frame.

> why the do-while is good in this case, and not simply brackets?

So that the whole thing is one statement that needs a ;, just like a
normal function call.  If it were brackets, you couldn't do

if(x) SAFE_ALLOCA(...);
else y=x;

> I see that inside unbind_to, the symbols are unbounded 1 by one. Why the
> specpdl_ptr is not decremented directly with count ?

Because you need to do something with each record: restore old values for
symbols, call functions registered with record_unwind_protect(), etc.

> Probably because unbind_to is called from lisp code by (throw 'symbol
> value), and specpdl_ptr must decrement 1 by 1 until the 'symbol is dound
> on the stack ?

catch-tags are searched separately: see struct catchtag.

> Apart from (throw ... ), is which other situation unbind_to is called ?

The other important one is Fsignal (quit and other errors).

> I see that GCPROx macros are used to protect the variables of type Lisp
> Object on the stack of C code (that the compiler creates), not to protect
> the lisp objects in specpdl. The GCPRO protection is against the algorthm
> of conservative stack. Am I right ?

I believe the GCPRO draws the attention of the stack checker to those Lisp
objects to make sure that they're not collected.


This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during

reply via email to

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