[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: advice needed for multi-threading patch
From: |
Stefan Monnier |
Subject: |
Re: advice needed for multi-threading patch |
Date: |
Wed, 26 Aug 2009 23:12:55 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) |
> 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
Re: advice needed for multi-threading patch, Tom Tromey, 2009/08/26
- Re: advice needed for multi-threading patch, Ken Raeburn, 2009/08/26
- Re: advice needed for multi-threading patch, Miles Bader, 2009/08/27
- Re: advice needed for multi-threading patch, Ken Raeburn, 2009/08/27
- Re: advice needed for multi-threading patch, Miles Bader, 2009/08/27
- Re: advice needed for multi-threading patch, Juri Linkov, 2009/08/28
- Re: advice needed for multi-threading patch, Miles Bader, 2009/08/28
- Re: advice needed for multi-threading patch, Juri Linkov, 2009/08/28