[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:45:43 +0300

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> Date: Sat, 08 Jul 2023 12:01:00 +0000
> Eli Zaretskii <eliz@gnu.org> writes:
> >> > 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?
> >> 
> >> To signal an error.
> >
> > Great! that means in practice no existing Lisp program could ever run
> > in a non-main thread.  It isn't a very practical solution.
> >
> > Besides, non-main threads do sometimes legitimately need to prompt
> > the user.  It is not a programmer's error when they do.
> As an alternative async threads can be temporarily changed to
> cooperative in such scenario.

That doesn't help, because, as I said, we don't have a good solution
for this dilemma even for the current Lisp threads.

> They will already have to wait synchronously when consing new objects
> anyway.

This issue about display and prompting the user is not the same as
interlocking.  The latter can be solved by waiting, but the former

reply via email to

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