Re: "concurrency" branch updated

[Ken Raeburn <raeburn@raeburn.org>]

> On Nov 3, 2015, at 11:29, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Ken Raeburn <raeburn@raeburn.org>
>> Date: Tue, 3 Nov 2015 04:40:25 -0500
>> Cc: "emacs-devel@gnu.org discussions" <emacs-devel@gnu.org>
>> 
>> 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