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

[Emanuel Berg]

Drew Adams wrote:

>> 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.

Yes, again one would have to agree on a general model first.
It would not be an abstraction only, but also a blueprint what
we want to achieve.

Then one would have to go thru all the cases where the global
state is interacted with and come up with ways how those cases
are to be changed so that they don't break existing code,
while also making sense in a multi-thread environment.

No solution or implementation are allowed to break existing
code, so that would be the minimum. And anything more than
that, they would have to make as much sense as possible in the
new, multi-threaded environment.

Global/dynamic/special variables would be one such case - or
rather, several cases, as you can interact with those by means
of several Lisp constructs, be it `setq' or `let' or whatever
else there is. It would all have to be covered one by one.

We now what `setq' does it a global/dynamic/special
variable now, in single-threaded Emacs. What would it do in
a multi-threaded Emacs? That does not break code written for
the old, single-threaded one? And so on.

-- 
underground experts united
https://dataswamp.org/~incal