Re: "concurrency" branch updated

[Ken Raeburn]

> On Nov 3, 2015, at 11:29, Eli Zaretskii <address@hidden> wrote:
> 
>> From: Ken Raeburn <address@hidden>
>> Date: Tue, 3 Nov 2015 04:40:25 -0500
>> Cc: "address@hidden discussions" <address@hidden>
>> 
>> At some point, we’ll want to demonstrate practical utility; not a trivial 
>> demo program that displays a few messages, and nothing on the scale of 
>> rewriting all of Gnus to be multithreaded, but somewhere in between.  I’m 
>> not sure what would be a good example.  A version of generator.el that uses 
>> threads instead of the CPS transformation of everything is a possibility, 
>> and it would probably simplify the writing and compiling of the generators, 
>> but it’d probably be more heavy-weight at run time.  Prefetching files’ 
>> contents, or searching already-loaded files, while tags-query-replace waits 
>> for the user to respond to a prompt?  Improving fontification somehow?
> 
> Given that only one thread can run Lisp, is the above even possible?

Implementing a generator with a thread seems somewhat straightforward, needing 
some sort of simple communication channel between the main thread and the 
generator thread to pass “need next value” and “here’s the next value” messages 
back and forth; some extra work would be needed so that dropping all references 
to a generator makes everything, including the thread, go away.  Raising an 
error in the thread’s “yield” calls may be a way to tackle that, though it 
changes the semantics within the generator a bit.

For prefetching file contents or searching existing buffers, the “main” thread 
can release the global lock when it prompts for the user’s input, and a 
background thread can create buffers and load files, or search buffers for 
patterns, tossing results onto some sort of queue or other data structure for 
consumption by the main thread when it finishes with the file it’s on.

Inserting a file’s contents or searching a large buffer can take a long time, 
though, so these could make the interactive experience sluggish at times 
depending on what’s going on in background, unless we find a way to do some of 
these operations without holding the global lock.  (Aside: Has anyone thought 
about applying JIT native code generation or translation-to-C to regular 
expressions?)  And loading a file can prompt for local variable settings and 
such, which could get kind of confusing if mixed with tags-query-replace 
prompting relating to a different file, but refactoring insert-file-contents 
into a minimal file-reading routine that does no Lisp callbacks and another to 
deal with file name handlers and hooks and such could let us do the former on a 
helper thread and the latter (which could prompt the user) in the main thread 
at the expected time.

Both of those examples are mainly about running some extra work in the moments 
while we’re waiting for the user to respond to a prompt.  We may be able to do 
the same with idle timers or other such mechanisms.  In cases like that, I 
think it may come down to whether it’s easier and/or more maintainable to write 
code that cranks through the next step of an explicitly managed state machine, 
or structured code that maintains its state in program counters and variables 
local to each stack frame… sometimes it’s one, sometimes it’s the other.

As to fontification… I expect the code is pretty tight now, but maybe someone 
who knows that code has some insight into whether we could do it better with 
more CPU cores available.

So… yeah, I think some of them are possible, but I’m not sure any of them would 
be a particularly good way to show off.  Got any suggestions?


> 
>> Understood.  I think there may also be places where we could use threads 
>> less visible to the Lisp world; TLS and redisplay come to mind.
> 
> Given the general model-view-controller design of Emacs and the
> structure of its main loop, is making redisplay run in a separate
> thread really viable?

I’m not sure.  I’m not picturing redisplay running concurrently with Lisp so 
much as redisplay on display 1 running concurrently with redisplay on display 
2, all happening at the same point in the code where we now run redisplay.  
(Ignoring for the moment the bits where redisplay can trigger Lisp evaluation.)

Under X11 I doubt trying to process different frames on the same display in 
different threads would help at all, given that the data still all goes through 
one network connection.  I expect that display updates on Windows, being on the 
local machine, are fast enough that even if concurrent updates by two or more 
threads go faster than fully serialized updates, it wouldn’t make much 
difference in the user experience.  Though I am making some assumptions that 
redisplay isn’t doing many costly calculations compared to the cost of pushing 
the bits to the glass.

I suspect TLS is probably the more interesting case.

Ken