[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 09:31:34 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
>>>>> "Stefan" == Stefan Monnier <address@hidden> writes:
Tom> ... which brings me to my problem. I'd also like to apply a similar
Tom> treatment to buffer-local variables. However, those do not have
Tom> convenient accessor macros, and before starting the laborious task of
Tom> wrapping all buffer field accesses, I thought I'd ask for advice. Is
Tom> this a sane way to proceed? Should I do something different? Could I
Tom> get such a patch in before the rest of this work, just to make my local
Tom> divergence smaller?
Stefan> I'm not sure I understand what you want to do and which problem you want
Stefan> to solve.
I'm trying to properly implement per-thread let binding in the presence
of buffer-local variables.
I was planning to do this by inserting a thread-based lookup anywhere a
buffer-local was accessed. However, to do this, I need to insert a
function call anywhere a field corresponding to a DEFVAR_PER_BUFFER is
used.
So, e.g., I would like to change:
b->major_mode = Qfundamental_mode;
to:
BUFFER_MAJOR_MODE (b) = Qfundamental_mode;
Doing this transform for all 54 DEFVAR_PER_BUFFER fields is a big pain,
though, so I thought I'd ask about it first.
Stefan> In my mind, in the first iteration of "adding multithreading
Stefan> to Emacs", no buffer could have two active threads at the same time
Stefan> (i.e. set-buffer would impose some kind of synchronization). In such
Stefan> a context, I think that buffer-local variables (and fields in the buffer
Stefan> structures) don't need any special treatment, right?
I will try that.
Tom> I'll also note that the above approach does not work for DEFVAR_INT.
Tom> I have a plan for those but I fear it is somewhat expensive. If you
Tom> have an idea...
Stefan> You can start with
Stefan> #define Vfoo XINT(*find_variable_location (&impl_Vfoo))
Stefan> and then fix up all the cases where the variable in accessed as
Stefan> an lvalue. In general, I'm not opposed to introducing macros
Stefan> for such accesses in the trunk, if it can make such work easier.
Yeah, this was my plan :-)
Tom
- Re: advice needed for multi-threading patch, (continued)
- 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
- Re: advice needed for multi-threading patch,
Tom Tromey <=
Re: advice needed for multi-threading patch, Giuseppe Scrivano, 2009/08/28