Re: Questions about throw-on-input

[Philipp Stephani <p.stephani2@gmail.com>]

Am Do., 14. Mai 2020 um 16:24 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Thu, 14 May 2020 10:32:44 +0200
> > Cc: Alexander Miller <alexanderm@web.de>, Emacs developers <emacs-devel@gnu.org>,
> >       Stefan Monnier <monnier@iro.umontreal.ca>, yyoncho <yyoncho@gmail.com>
> >
> > > Your ideal world seems to be based on an editor design that is very
> > > different from what Emacs is.  The absolute majority of objects which
> > > an average Lisp program manipulates are globally visible -- buffers,
> > > windows, frames, global variables, the obarray, etc., and doing that
> > > in non-blocking ways is not really trivial.
> > >
> >
> > And that's what I'd call one of the biggest problems in current
> > Emacs's design. Much of the development in programming practices over
> > the last few decades has been moving away from global mutable state,
> > in order to increase robustness and predictability, and also to make
> > concurrency without subprocesses possible.
>
> My point is that adding multithreading to Emacs will need rethinking
> and redesigning many core features, so it is a large job.

Yes, I fully agree.

Just to reiterate, because I think this point can't be stressed
enough: It's not possible to just run existing code in background
threads and expect it to work. It's also not possible to have the
ELisp interpreter yield automatically. Even with a GIL, a yield means
that arbitrary state changes (point moving, buffers vanishing,
variable values changing, etc.) can happen. Therefore it's crucial
that the interpreter yield only at very specific points (roughly those
where other asynchronous code is allowed to run, e.g.
accept-process-output or sleep-for). Java/C++-style multithreading is
simply not possible with the current design of ELisp.
I'd therefore recommend to focus on a combination of explicit
asynchonicity without multithreading (using continuations or promises)
and webworker-style background processing (with complete state
isolation and explicit copying of data).