Re: advice needed for multi-threading patch

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Oh, right... I meant to ask you at some point if there was a reason for that
> other than streamlining performance a little.

It has nothing to do with performance, and everything to do with code
cleanliness and robustness.  Using Lisp_Symbol* rather than Lisp_Object
makes it clear (both to the reader and to the type-checker) that the
object received (or returned) can only be a symbol.

> Now, with the GC work in progress, it's possible that during conservative
> stack scanning, the pointer to the big structure might be  enough to cause
> it to not get freed up; I'm not that familiar with the  new code.  But the
> conservative approach seems to be to keep the SCM  (Lisp_Object) values live
> as long as the pointed-to data is needed.

Emacs's stack scanning already has to check both Lisp_Object values
(i.e. tagged pointers) and plain direct untagged pointers.  This was
needed IIRC because even if the C code appears to hold on to
a Lisp_Object value, the optimizer may get rid of it and only keep the
untagged pointer.

So, I think Guile's stack scanning will have to do that as well, I think
(regardless of Emacs integration).

> However, there's also the little matter that eventually I want to make Emacs
> use Guile symbols for its own symbols, for better interaction  between the
> languages.  That means that "struct Lisp_Symbol" would go  away.  If it's
> part of the internal function interfaces, that means  the Guile work has to
> have greater divergence from the upstream code.

We'll cross that bridge when we get there.  I think we'll find that the
particular interface used by the function will be a very minor issue
(the whole function will probably need to be rewritten).


        Stefan