Re: Info: No GIL Multithreading strat for Python

[Arthur Miller <arthur.miller@live.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Sun, 03 Mar 2024 12:50:18 +0100
>> 
>> 
>> I just stumbled over an intersting presentation of a multithreading experiment
>> for a "no-gil" Python, with relatively well-explained strategy they use,
>> problems they face and what it offers:
>> 
>> https://www.youtube.com/watch?v=rImAmkS2ySE&t=2s
>> 
>> The presentation is about ~ ½ year old, I have no idea what is the status and
>> how well it works. But some of what they discuss is perhaps of the interest for
>> emacs devs.
>
> 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? Python is not Elisp; Elisp is not
Python, and Python interpretter is not Emacs, and Emacs is not Python
interpretter. I think it is self-evident. Sure, nobody said they are the same?

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.

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

> far from as possible.  If Emacs crashes, users blame Emacs, not the
> Lisp they wrote.

Mnjah; I think you are little bit unjust to your users here :). I think that
people do understand when they write bad code and crash Emacs.

> So there's a large difference, and therefore not every technique used

Naturally, there is a difference between a text editor and an interpretter; but
Emacs happens to be both at the same time; and the interpretter part is rather
similar to Python.

> by a programming language can be used by Emacs to achieve similar
> goals.

Of course; and nobody said that you pick any random strat for some programming
language implementation and apply to Emacs.

However, what they are trying to solve there, is potentially very similar to
what we have in Emacs too.

Anyway, just information sharing.