Re: Questions about throw-on-input

[Daniel Colascione <dancol@dancol.org>]

On 5/11/20 10:39 AM, Alexander Miller wrote:
>  >> 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. 

Sure. You can also have Emacs run itself as a subprocess.

> 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.

Is TSan is just getting confused by the global lock? We don't have any 
parallelism, so data races shouldn't be happening at all.