Re: Concurrency via isolated process/thread

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Great! that means in practice no existing Lisp program could ever run
> in a non-main thread.  It isn't a very practical solution.

Number and text crunching tasks (think Semantic, or JSON parsing for
LSP) don't need to sleep or read keyboard input.

> Besides, non-main threads do sometimes legitimately need to prompt
> the user.  It is not a programmer's error when they do.

They should then devise mechanisms for communicating with the main
thread.

> I don't think such a simplistic solution suits a program such as
> Emacs.

It is the only possible solution, as long as Emacs wants to keep working
with other window systems.  Even our limited threads cannot work with NS
and GTK in their present state: the toolkit aborts or enters an
inconsistent state the instant a GUI function is called from a thread
other than the main thread.

> Fixed how?

By replacing `sit-for' with `sleep-for' (and in general avoiding
functions that call redisplay or GUI functions.)

> The above doesn't do any editing, it just accesses buffer text without
> changing it.

I intended to include ``changing point'' in my definition of ``modifying
the buffer''.

> Why are we talking about multiple threads at all? don't we want to
> allow some Lisp code run from non-main threads?

That code will have to be specifically written for running outside the
main thread, of course, obviating the need to rewrite all of our
existing code.

> Using a snapshot of some global resource, such as buffer text, works
> only up to a point, and basically prohibits many potentially
> interesting uses of threads.  That's because such snapshotting assumes
> no significant changes happen in the original objects while processing
> the snapshot, and that is only sometimes true.

We could also allow Lisp to lock a buffer by hand.