[Top][All Lists]

[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 17:12:37 +0300

> From: Po Lu <luangruo@yahoo.com>
> Cc: yantar92@posteo.net,  emacs-devel@gnu.org
> Date: Sat, 08 Jul 2023 19:54:59 +0800
> 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.

Are they allowed to, say, write some data to a file?  If so, they
might need to ask the user whether its okay to overwrite an existing

IOW, I think you have a very narrow idea of "number and text crunching
tasks" that could benefit from threads.  For example, one of the
frequent requests is to run the part of Gnus that fetches email and
articles in a separate thread -- if this is okay for "number and text
crunching tasks", then it is likely to prompt users.

> > 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.

We are mis-communicating.  My point is that it is almost impossible to
take an existing non-trivial Lisp program and let it run from a
non-main thread without bumping into this issue.  Your responses
indicate that you agree with me: such Lisp programs need to be written
from scratch under the assumption that they will run from a non-main

How is this compatible with the goal of having threads in Emacs, which
are to allow running Lisp code with less hair than the existing timers
or emacs-async?

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

So programs running in non-main threads will be unable to do stuff
like show progress etc.?  That's not very encouraging, to say the

> 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.


This basically means rewriting most of Emacs.  Because most APIs and
subroutines we use in every Lisp program were not "specifically
written for running outside the main thread".  So we'll need special
variants of all of those to do those simple jobs.

> > 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.

Same problem here.

reply via email to

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