bug#65837: 30.0.50; Debugger in non-main threads

[Eli Zaretskii <eliz@gnu.org>]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: 65837@debbugs.gnu.org
> Date: Sat, 09 Sep 2023 17:35:22 +0200
> 
> On Sat, Sep 09 2023, Eli Zaretskii wrote:
> 
> > AFAIR, it is not trivial to improve
> > the thread error handling significantly, but patches are welcome, of
> > course.
> 
> Is there a design/plan for how recursive-edit is supposed to work in
> non-main threads?

Not that I know of, no.  But you seem to be asking mainly about
reading events, not about recursive-edit?

> E.g. some options that come to mind:
> 
> 1) It should be allowed without restriction (what currently seems to be
> happening).

Almost: the keyboard input is processed by the thread which "grabs"
it.  AFAIR, this is usually the main thread, but it is not enforced.

> 2) There should be some locking/multiplexing scheme so that only some
> "foreground thread" is allowed to read events from the keyboard.
> 
> 3) Only the main thread is allowed to call recursive-edit; all other
> threads have to communicate with the main thread in some way.  (Maybe
> there should be one thread per terminal that runs a command loop, but
> that's an exotic detail.)

User interaction when multiple threads are present is an issue we
didn't figure out.  I think based on past discussions it is quite
clear that some kind of protocol or discipline is needed to avoid
creating a terrible mess whereby the user could even completely lose
the ability to interact, but it is not clear what that protocol should
be and how it would work.

At least the two alternatives you listed above each have problems that
need to be resolved.  The main issues, AFAIR, are:

  . if only one thread can read input, what do other threads do when
    they want to ask the user some question? if they should wait, then
    this should be somehow incorporated in the thread_select machinery
  . how would the user know which thread prompts him/her? (this is
    sometimes important)
  . what about just displaying messages, without any input -- should
    that be allowed from any thread, or should there be
    synchronization here as well? what about redisplay in general?

This all is exacerbated by two important factors:

  . there's no scheduler between threads, they basically schedule
    themselves, so there's no entity besides the threads themselves to
    implement whatever protocols are needed for input multiplexing
  . Emacs doesn't have a separate input mechanism: input from
    minibuffer just reuses the normal editing and display
    capabilities, so whatever we do about multiple threads will
    directly affect these general-purpose capabilities

Feel free to suggest possible solutions and ideas, just not here, on
emacs-devel.