Re: Concurrency via isolated process/thread

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sat, 08 Jul 2023 10:53:59 +0000
> 
> Ok. I tried to find an example myself by looking into `char-after'.
> I can see 
> CHAR_TO_BYTE->buf_charpos_to_bytepos->buf_next_char_len->BUF_BYTE_ADDRESS
> and
> FETCH_CHAR->FETCH_MULTIBYTE_CHAR->BYTE_POS_ADDR
> 
> Will blocking GC for the duration of CHAR_TO_BYTE and buf_next_char_len
> be a problem?

Not by itself, no.  But if you go this way, you eventually will lock
everything all the time.

> >> By transforming some of the global state variables into thread-local
> >> variables.
> >
> > Which variables can safely and usefully be made thread-local?
> 
> PT, ZV, BEGV

Even that is not enough: you forgot the gap.

> and the buffer-local variables that are represented by the
> global C variables.

That's a lot!

> >> > I don't see how one can write a useful Lisp program with such
> >> > restrictions.
> >> 
> >> Pure, side-effect-free functions, for example.
> >
> > I don't see how this could be practically useful.
> 
> For example, `org-element-interpret-data' converts Org mode AST to
> string. Just now, I tried it using AST of one of my large Org buffers.
> It took 150seconds to complete, while blocking Emacs.

It isn't side-effect-free, though.

I don't believe any useful Lisp program in Emacs can be
side-effect-free, for the purposes of this discussion.  Every single
one of them accesses the global state and changes the global state.

> > ... Besides the basic
> > question of whether a useful Lisp program can be written in Emacs
> > using only side-effect-free functions
> 
> Yes. I mean... look at Haskell. There is no shortage of pure functional
> libraries there.

I cannot follow you there: I don't know Haskell.

> > .. , there's the large body of
> > subroutines and primitives any Lisp program uses to do its job, and
> > how do you know which ones of them are side-effect-free or async-safe?
> 
> (declare (pure t))

How many of these do we have, and can useful programs be written using
only those?  More importantly, when you call some function from
simple.el, how do you know whether all of its subroutines and
primitives are 'pure'?

> > To take just one example which came up in recent discussions, look at
> > string-pixel-width.  Or even at string-width.
> 
> Those must either be blocking or throw an error when called from async
> thread.

So we will always block.  Which is what we already have with the Lisp
threads.

> Just to be clear, it is not a useful aim to make any arbitrary Elisp
> code asynchronous. But if we can at least allow specially designed Elisp
> to be asynchronous, it will already be a good breakthrough.

No, it will not.  It will be a fancy feature with little or no use.

> And later, in future, if we can manage to reduce the amount global state
> in Emacs, more Elisp code may be converted (or even work as is)
> asynchronously.

If we don't have a clear path towards that goal today, and don't even
know whether such a path is possible, it will never happen.

> Remember the lexical binding transition. I was not refused because some
> Elisp code failed to work with it.

Lexical binding is nothing compared to this.