[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch for fields of `struct buffer'
From: |
Tom Tromey |
Subject: |
Re: Patch for fields of `struct buffer' |
Date: |
Mon, 31 Jan 2011 12:57:52 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) |
RMS> I don't think preemptive thread switching is a sensible goal. It
RMS> is so much trouble that it isn't worth doing even in the long term.
I don't think it is nearly that bad.
RMS> That is more limited than I thought it was. If it is needed for
RMS> non-preemptive thread switching, the benefit would justify the cost,
RMS> but I think it isn't needed for that. If this is would only be needed
RMS> for preemptive thread switching, I think the loss of clarity and
RMS> naturalness of the code is enough reason not to do it.
Ok. I will stop work on this patch, then. I am not sure if I am
interested in working on threads done the other way, I will have to
think about it.
You might want to consider backing out my earlier patch. It won't be
needed either.
Tom> * DEFVAR_LISP and other true globals.
Tom> These will be handled efficiently by using pointer tricks. Each
Tom> global will have a corresponding pointer to it, and each thread will
Tom> have its own copy of all of these.
RMS> That is incorrect semantics. Most ofthese values should be shared
RMS> between all the threads that don't bind them somehow, just as they
RMS> are shared between all the buffers that don't bind them.
I wasn't clear enough.
For each global variable, the per-thread pointer will ordinarily point
to the main thread's slot. When the variable is let-bound, thus
becoming thread-local, the pointer will be redirected to the slot in the
per-thread structure. When the outermost let-binding is undone, the
pointer will be reset to the main thread's slot.
I think this implements the correct semantics: a global variable's value
is shared between all threads, and a let-bound variable is thread-local.
RMS> Are you saying you would like to change it so that every access to
RMS> a Lisp variable requires indirecting?
Only potentially -- like today.
RMS> At present, every access to a Lisp variable requires a test for
RMS> possible indirections, but most variables don't have an indirection.
That will continue to be the case. We can add another value to enum
symbol_redirect to indicate variables which are potentially
thread-local.
Tom
- Re: Patch for fields of `struct buffer', (continued)
- Re: Patch for fields of `struct buffer', Stefan Monnier, 2011/01/31
- Re: Patch for fields of `struct buffer', Tom Tromey, 2011/01/31
- Re: Patch for fields of `struct buffer', Stefan Monnier, 2011/01/31
- Re: Patch for fields of `struct buffer', David De La Harpe Golden, 2011/01/31
- Re: Patch for fields of `struct buffer', Tom Tromey, 2011/01/31
- Re: Patch for fields of `struct buffer', David De La Harpe Golden, 2011/01/31
- Re: Patch for fields of `struct buffer', Richard Stallman, 2011/01/31
- Re: Patch for fields of `struct buffer', Richard Stallman, 2011/01/31
- Re: Patch for fields of `struct buffer',
Tom Tromey <=
- Re: Patch for fields of `struct buffer', Tom Tromey, 2011/01/31
- Re: Patch for fields of `struct buffer', Eli Zaretskii, 2011/01/31
- Re: Patch for fields of `struct buffer', Stefan Monnier, 2011/01/31
- Re: Patch for fields of `struct buffer', Tom Tromey, 2011/01/31
- Re: Patch for fields of `struct buffer', Stefan Monnier, 2011/01/31