[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about throw-on-input

From: Daniel Colascione
Subject: Re: Questions about throw-on-input
Date: Mon, 11 May 2020 19:39:33 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]