bug#57196: 28.1.90; An idea to allow background (low-priority) threads

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Date: Sun, 14 Aug 2022 12:12:20 +0800
> 
> Emacs does have a limited concurrency support via Threads, which is,
> unfortunately, mostly a toy feature I haven't seen being used a lot.
> 
> All my attempts to implement some real functionality using threads
> failed because it is very hard to create real-life threads that do not
> noticeably block Emacs. Most of the time, Emacs gets quite sluggish,
> even if the thread yields frequently.
> 
> Such situation sounds similar to what one may get with 1CPU and
> multiple processed fighting for the CPU time. This is something that
> used to be solved with nice command.
> 
> Could something like nice be implemented for Elisp threads?

Our "scheduler", such as it is, is in thread.c:really_call_select.  It
basically releases the global lock and lets the first thread waiting
on the lock to acquire the lock.  If someone wants to implement a
smarter lock-grabbing logic with some kind of "nice" capability, AFAIU
that's the place to look and modify.

TBH, I'm not really sure your analysis, which basically says this is a
problem with thread "equality", is correct.  Did you try to see what
causes the sluggish operation in the cases where you saw it?

> I imagine that something similar could be done for threads.
> `make-thread' could allow some kind of priority setting that will limit
> its execution time to comfortable levels, so that the user in main
> thread can actually interact with Emacs without noticing anything.

What mechanism will stop the running thread that has exceeded its
allotted time?  In the current implementation, the thread stops itself
when it calls a small set of primitives, but with your proposal we'd
need to make the "scheduler" run in a separate thread, which would
mean a complete redesign of how threads are scheduled.