Re: Some experience with the igc branch

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 29 Dec 2024 11:30:22 -0800
> Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com,
>  emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 12/29/24 11:20, Eli Zaretskii wrote:
> > if a non-main thread's Lisp function keeps running forever,
> > never calling any primitives that release the lock, that thread will
> > run forever, and the main thread will never get a chance.  Lisp
> > programs that cause this are considered buggy, of course.
> > 
> >> I don't see this issue documented explicitly in doc/elisp/threads.texi.
> >> Should it be?
> > I will have an opinion when I better understand what "it" is in this
> > case.  I hope this is just a misunderstanding.
> 
> It's the issue summarized in your paragraph that I quoted above, along 
> with its consequences, which are obvious to someone who knows how Emacs 
> Lisp threads work but not so obvious to newcomers who may have several 
> notions of "threads" rattling around in their heads.
> 
> It's not just that the main thread never gets a chance: it's that 
> signals are effectively ignored.

If the signal handler gets invoked and does its thing, how can that be
considered as "effectively ignoring" the signal?  Can you describe on
some concrete example how signals should work in some situation, and
then how you think that is changed when a on-main Lisp thread holds
the global lock, which leads you to say the signal is "ignored"?

> Does the same thing happen with C-g? If so, I'd think that should also 
> be documented in threads.texi.

C-g generates a signal only on TTY frames.  Is that what you mean?

And when you say "the same happens", what do you mean by that?  If you
somehow have the impression that C-g doesn't work when a non-main
thread runs, then this impression is incorrect.