Re: Concurrency

[Tom Tromey]

Stefan> Actually, we need both: we need to document the changes, as seen
Stefan> by an Elisp programmer (fits in etc/NEWS), and we need to
Stefan> document the way it works internally, the invariants upon which
Stefan> it relies and things like that.

I can supply some of the raw data here, if not the commits.

We added a few new lisp objects:

* thread_state.  This represents a single thread.  Before dumping, only
  one thread may exist.

  Some C variables which were formerly global were moved into this
  struct, and replaced with a redirecting #define.  E.g.:

  /* Pointer to beginning of specpdl.  */
  struct specbinding *m_specpdl;
#define specpdl (current_thread->m_specpdl)

  Exactly which things needed to be in this structure was determined in
  an ad hoc way; mostly by looking at `nm' to see what globals were
  interesting.

* Lisp_Mutex.  A mutex, should be obvious.

* Lisp_ThreadLocal.  This is used to represent a thread-local binding.
  It has a slot for the global value, and an alist mapping threads to
  a thread-local slot.  If a thread is not in the alist, the global
  binding is used.

  A Lisp_ThreadLocal can appear in a number of places, e.g. in a
  variable binding, in a Lisp_Object global variable, etc.

  We rewrote a lot of the C code to automatically indirect through a
  Lisp_ThreadLocal, when found.  There is a new header, globals.h, which
  has many lines of the form:

#define Vafter_change_functions *find_variable_location 
(&impl_Vafter_change_functions)

  A couple things about this line:

  * The expansion is chosen so that both rvalue and lvalue uses work.
  * The underlying global is renamed to catch any errors.

There are other changes (in the GC, in the binding code) but I think
those are relatively self-explanatory in the code... at least, hopefully
as much as the code was before.

Tom