Re: Concurrency via isolated process/thread

[Ihor Radchenko <yantar92@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Can you please provide an example about "surprised"? Do you mean that
>> buffer->pt will no longer be accurate? Something else?
>
> Not pt but the pointers to buffer text and the gap.  Those determine
> the address of a given buffer position in memory, and are used when a
> Lisp program accesses buffer text in any way.  GC can change them if
> it decides to relocate buffer text or compact the gap.

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? GC between the calls to CHAR_TO_BYTE and
buf_next_char_len, if it relocates buffer text/gap will not break
anything, AFAIU.

>> >> Then the question is: can the global state be reduced?
>> >
>> > By what measures?  Please suggest something concrete here.
>> 
>> 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, and the buffer-local variables that are represented by the
global C variables.

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

Or consider building large completion table.
Or parsing HTML DOM string into sexp.
Or JSON passed by LSP server.

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

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

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

---

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.

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.

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

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>