emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Concurrency via isolated process/thread


From: Eli Zaretskii
Subject: Re: Concurrency via isolated process/thread
Date: Sat, 08 Jul 2023 10:21:08 +0300

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 08 Jul 2023 08:44:17 +0800
> 
> Ihor Radchenko <yantar92@posteo.net> writes:
> 
> > So, we can hold when interrupt_input_blocked is changed until the thread
> > becomes main thread?
> 
> IMHO there should only be a single main thread processing input and
> display, since that's required by most GUI toolkits.

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?

This is a problem even with the current Lisp threads, and we don't
have a satisfactory solution for it.  (We discussed this a couple of
years back, but didn't arrive at any useful conclusions, AFAIR.)

Personally, I don't believe this aspect can be solved without very
significant redesign of Emacs and -- what's more important -- without
rewriting many Lisp programs to adhere to the new design.  Searching
for yes-or-no-p and y-or-n-p are in Emacs alone brings 1500 hits.

> > Hmm. What about locking thread->current_buffer for all other threads?
> > This appears to solve the majority of the discussed problems.
> 
> If you're referring to prohibiting two threads from sharing the same
> current_buffer, I doubt that's necessary.
> 
> > I am not sure how to deal with buffer->pt for multiple threads running
> > in the same buffer.
> 
> C functions which modify the buffer should be interlocked to prevent
> them from running simultaneously with other modifications to the same
> buffer.

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

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).
IOW, we are no longer talking about some change to Emacs, we are
talking about rewriting most or all of Emacs!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]