[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: advice needed for multi-threading patch
From: |
Tom Tromey |
Subject: |
Re: advice needed for multi-threading patch |
Date: |
Wed, 26 Aug 2009 10:08:01 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
>>>>> "Ken" == Ken Raeburn <address@hidden> writes:
Ken> I hope you and Daniel and I aren't doing redundant work.
Unless your changes apply to Emacs I don't think they are really
redundant. I think the key thing is agree how it ought to work, so we
end up with the same model, but I don't anticipate any problems there.
Ken> I've written similar elisp code for doing transformations of patterns
Ken> within the Emacs code -- mostly more localized things like "XCONS
Ken> (expr)->car" to "XCAR (expr)", but with support for somewhat complex
Ken> values of "expr" that have to have balanced parens, etc.
If you still have these, I would appreciate a copy, so that I don't have
to reinvent them. Are they in your git repository?
Ken> I wonder if anyone's looking at collecting elisp tools for C
Ken> refactoring somewhere.
There may be some on the CEDET site. I don't remember seeing any on the
wiki or elsewhere.
Ken> Should I take this to mean you've already dealt with the buffer-local
Ken> variables created by make-variable-buffer-local, which don't live in
Ken> the buffer structure?
Well... nominally. It is still a buggy mess.
Ken> If so, I wonder if you can make use of those
Ken> changes, by replacing XBUFFER(b)->thing with SYMBOL_VALUE(Qthing)
Ken> where Qthing holds a symbol that's marked as buffer-local; then all
Ken> the changes for the interaction between thread-local and buffer-local
Ken> bindings would be localized in indirect_variable and friends, which
Ken> would then have to deal with both Lisp_Misc_Buffer_Objfwd and
Ken> Lisp_Misc_Buffer_Local_Value.
I will have to think about this. This would imply removing all those
slots from struct buffer; I suppose my concern would be that the result
would be too inefficient.
I've also been considering a similar thing for the Vfoo globals: remove
them and have the C code always refer to them via SYMBOL_VALUE.
Tom
Re: advice needed for multi-threading patch,
Tom Tromey <=
- 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
- Re: advice needed for multi-threading patch, Miles Bader, 2009/08/28
Re: advice needed for multi-threading patch, Richard Stallman, 2009/08/29
Re: advice needed for multi-threading patch, Stefan Monnier, 2009/08/26