RE: [External] : Re: Emacs design and architecture. How about copy-on-write?

[Drew Adams]

(Caveat: Not really following this thread,
and I'm no expert on concurrency etc.)

> Global/dynamic/special
> variables are the exception and not the norm - yes, as we hear
> from the name "special" BTW :) - and yes, they will have to be
> locked one by one and for as long as it takes for the
> execution to proceed safely.

I hate to say it, but one of the points (the
only point?) of global/dynamic/special in Lisp
is to be able to affect other code anywhere,
including code that isn't yet written.

https://www.gnu.org/software/emacs/emacs-paper.html#SEC17

There's no overall, top-level director that
manages where dynamic bindings should have
their effect and retain their values.

That's the point: the bindings are dynamic.

There's really no such thing as dynamic scope.

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node43.html#SECTION00700000000000000000

  ... it is convenient to define dynamic scope
  to mean indefinite scope and dynamic extent.
  
  Thus we speak of "special" variables as
  having dynamic scope, or being dynamically
  scoped, because they have indefinite scope
  and dynamic extent: a special variable can
  be referred to anywhere as long as its
  binding is currently in effect.

  The term ``dynamic scope'' is a misnomer.
  Nevertheless it is both traditional and useful.

Dynamic bindings have _indefinite scope_:

  References may occur anywhere, in any program.

Dynamic bindings have _dynamic extent_:

  References may occur at any time in the interval
  between establishment of the entity and the
  explicit disestablishment of the entity.

  As a rule, the entity is disestablished when
  execution of the establishing construct completes
  or is otherwise terminated. Therefore entities
  with dynamic extent obey a stack-like discipline,
  paralleling the nested executions of their
  establishing constructs.

So if you want to control dynamic bindings wrt
concurrency, you really need to implement some
kind of _transactions_, which will create and
terminate the bindings as needed/declared.

Maybe an alternative could be to use a kind of
optimistic concurrency, using, e.g., a kind of
ETAG value (e.g., on special vars or sets of
them).  That might be sufficient for a single
updating operation.

But to be able to control multiple updates of
multiple variables over a given duration, I
think some kind of transactions will need to
be implemented.  You commit the series of
updates for a given transaction only if other
sessions haven't modified the same variables
concurrently (as determined by ETAG values).