Re: Concurrency, again

[Ken Raeburn]

We’re getting quite a list of “coffee-break inducing moments”. :-)

To what’s been posted so far, I’ll add a couple of cases that I’ve run into 
trouble with, which might be helped in part with multiple threads:

- regexp scanning in a huge file that took so long my IM sessions would time 
out because the Emacs-based client code couldn’t respond to the server (which 
scanning also turned out not to be interruptible with ^G)

- file operations hanging for minutes at a time when an NFS session stalls due 
to network lossage, freezing the UI, causing IM session timeouts, etc; I’d love 
for auto-revert-mode type timestamp checking for buffers I’m not editing at the 
moment to not lock up my entire Emacs session in that situation, and it’d be a 
huge amount of work, but being able to cancel or abort a hung “save” or 
find-file operation would be pretty nice

Letting the IM client code use a helper thread for callbacks could help, as 
long as regexp scanning and file operations release the global lock.  Having 
the UI not freeze up during file operations is probably more complicated, 
especially if we want to let the user hit ^G and go do something else, since 
NFS operations tend (depending on implementation) to be uninterruptible.

In the latter case (and probably some others, like Perry’s video playback in an 
eww buffer), C-level threads mostly invisible to Lisp might suffice, but I 
think there are a number of cases where we do want concurrent evaluation of 
multiple bodies of Lisp code, which code is often most logically written in 
structured or functional programming style, not “massive pile of callbacks” 
style.