Re: Concurrency via isolated process/thread

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> That is already a problem, as long as we are talking about leaving
> most of Emacs application code intact.  How do you ensure only the
> main thread can process input and display?  A non-main thread can
> easily call some function which prompts the user, e.g., with
> yes-or-no-p, or force redisplay with sit-for, and what do you do when
> that happens?

To signal an error.  Threads other than the main thread should not call
such functions, which is the approach taken by most toolkits and window
systems.  (X being a notable exception, where every Xlib display is
surrounded by one massive lock.)

This will mean that most user facing Lisp won't be able to run in
parallel with the main thread, but that can be fixed, given enough time.
And it's not disasterous, seeing as _no_ Lisp can presently run in
parallel with the main thread.

> That's not enough!  Interlocking will prevent disastrous changes to
> the buffer object which risk leaving the buffer in inconsistent state,
> but it cannot prevent one thread from changing point under the feet of
> another thread.  Consider this sequence:
>
>   . thread A moves point to position P1
>   . thread A yields
>   . thread B moves point of the same buffer to position P2
>   . thread B yields
>   . thread A resumes and performs some processing assuming point is at P1

Lisp code that is interested in making edits this way will need to
utilize synchronization mechanisms of their own, yes.

> Without some kind of critical section, invoked on the Lisp level,
> whereby moving point and the subsequent processing cannot be
> interrupted, how will asynchronous processing by several threads that
> use the same buffer ever work?  And please note that the above is
> problematic even if none of the threads change buffer text, i.e. they
> all are just _reading_ buffer text.
>
> It follows that such asynchronous processing will have to be
> explicitly accounted for on the level of Lisp programs, which means
> thorough rewrite of most of Lisp code (and also a lot of C code).

Insofar as that Lisp code is actually interested in making use of
multiple threads.

> IOW, we are no longer talking about some change to Emacs, we are
> talking about rewriting most or all of Emacs!

I think that as long as we make the C text editing primitives robust
against such problems, authors of Lisp code that needs to edit buffer
text from multiple threads will devise appropriate synchronization
procedures for their specific use cases.  For example, to parse a buffer
in the background, Semantic may chose to create a new thread with a
temporary copy of the buffer that is being read.  Or, Gnus might do the
same to fontify a Diff attachment in an article.  Lisp changes can all
be accomplished gradually, of course, whereas the C-level changes will
have to be completed all in one go.

Thanks.