Re: Questions about throw-on-input

[Alexander Miller]

>> Do we want that?
>
> I don't know. But hanging because `select` doesn't return the needed
> information doesn't seem right either. Maybe rather than signal an
> error, we should somehow make the main thread run that code, so as to
> return the right answer?

That could be a game-changer, it would open up the path for making Elisp
a lot more asynchronous than it is now. You could load up heavy work on
a background thread, and (of course assuming it can be slit into smaller
pieces) simply yield whenever input is detected. And when the main
thread has done its part the worker would simply pick up again where it
left off.

That is something of a holy grail for many package developers like me -
to be able to *do things*, especially in the background, without
constant worry of freezing the UI.

I don't think this is possible right now, other than maybe with
awkwardly pushing around timers and while-no-input, or using mandatory
1ms pauses instead of proper yielding as in my benchmark, which is
probably not exactly ideal either.

And while we are on the topic of threads, I wonder what is the
maintainers' opinion on https://nullprogram.com/blog/2018/05/31/,
specifically this part:

> Update: ThreadSanitizer (TSan) quickly shows that Emacs’ threading
> implementation has many data races, making it completely
> untrustworthy. Until this is fixed, nobody should use Emacs threads
> for any purpose, and threads should disabled at compile time.