Re: Concurrency via isolated process/thread

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Fri, 07 Jul 2023 12:30:16 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> But 5% CPU time spend allocating memory is not insignificant.
> >
> > Once again, it isn't necessarily memory allocation per se.  For
> > example, it could be find_suspicious_object_in_range, called from
> > allocate_vectorlike.
> 
> I did not have ENABLE_CHECKING in this benchmark.
> It is just ./configure --with-native-compilation
> So, find_suspicious_object_in_range should not run at all.

Then maybe you should invest some serious time looking into this and
figuring out why this happens.  Although in my book 5% of run time or
even 10% of run time is not the first place where I'd look for
optimizations.

> maybe need to have multiple heaps.

All modern implementation of malloc already do use several different
heaps internally.

> >> If a thread is working with a temporary buffer and locks it, that
> >> buffer has almost 0 chance to be accessed by another thread.
> >
> > But "working on a buffer" requires access and modification of many
> > global structures.  Just walk the code in set-buffer and its
> > subroutines, and you will see that.
> 
> I was only able to identify the following:
> 
> interrupt_input_blocked
> current_buffer
> last_known_column_point

There are much more:

  buffer-alist
  buffer's base-buffer
  buffer's undo-list
  buffer's point and begv/zv markers
  buffer's marker list
  buffer's local variables

(Where the above says "buffer's", it means the buffer that was current
before set-buffer.)

> AFAIU, current_buffer might be made thread-local and
> last_known_column_point can be made buffer-local.

The current buffer is already thread-local.

> interrupt_input_blocked is more tricky. But it is just one global state
> variable. Surely we can find a solution to make it work with multiple threads.

Yes, but we have just looked at a single primitive: set-buffer.  Once
in the buffer, any useful Lisp program will do gobs of stuff, and each
one of those accesses more and more globals.  How do you protect all
that in a 100% reliable way? by identifying the variables and
structures one by one? what if tomorrow some change in Emacs adds one
more?

> >> Same with variables - even if some global variable needs to be locked,
> >> it is unlikely that it will need to be accessed by another thread.
> >
> > I think you misunderstand the frequency of such collisions.
> > case-fold-search comes to mind.
> 
> How so? What is the problem with a buffer-local variable that is rarely
> set directly (other than by major modes)? let-binding is common, but it
> is not a problem.

Searching for "setq case-fold-search" finds more than 30 hits in Emacs
alone.  And this variable is just an example.

Like I said: your mental model of the Emacs global state is too
optimistic.