Re: Info: No GIL Multithreading strat for Python

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 03 Mar 2024 20:01:06 +0100
> 
> > Python is a programming language, where the programmers are
> > responsible for what the parallel programs they write do and how do
> > they cope with the various dangers of concurrency.  If the program
> > crashes, the programmer has only him/herself to blame.
> 
> I am not sure what you are trying to say?

Just what I said: that problems with implementing concurrency in Emacs
are not problems of the Emacs Lisp programming language.  So they
cannot be solved solely by changing the language.

> Anyway; Python Intepretter and Emacs are not the same, but there are some
> important similarities and similar problems. What they are talking there might
> be an interesting multithreading strategy for Emacs as well. They have similar
> problem with the shared state.

No, the problems in Emacs are much harder, because the shared state
exists independently of the programs written in Emacs Lisp, and
because the way we write Emacs Lisp programs basically _requires_ the
shared state to exist.

> > By contrast, Emacs is a program that lets users process text in
> > various scenarios, where users expect Emacs to react gracefully to
> > errors.  Emacs the program has a very large global state that doesn't
> > work well with any concurrency, and which any programmer will keep as
> 
> Yes, we all know that, and that is what that presentation was about; that is 
> why
> I have hinted abou it.

Yes, we all know what you wanted to say.  And that is why I wrote the
response: to point out an important caveat.  So that people would keep
that in mind when they watch.