Re: "concurrency" branch updated

[Ken Raeburn <raeburn@raeburn.org>]

> I'm unfamiliar so far with the content of the concurrency branch, what changes
> it makes, and the threading model it proposes.  Could you please summarize the
> state of the art for me, so that I know what this branch entails?

The email threads that Eli pointed to are the best starting point. I’m doing some catching up myself; I haven’t worked on this branch until recently, though I've gotten a basic understanding of some of it through working on the merge.  I’ve got to dig through the emails from earlier reviews of the code and make some notes on things not yet done.  In addition to some proposed code changes, I’m sure at a minimum much more testing and bug fixing is needed, some assessment of the performance, and possibly some utility functions would be nice to have (e.g., mutex-try-lock, mutex-timed-wait).

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?

Concurrent execution of Lisp code is a way off, but IMHO a desirable thing to shoot for, if we want Emacs to get faster as machines go for multicore rather than faster clocks.  Currently, only one thread runs Lisp at a time, and switching can happen only at certain points (when explicitly requested, or when select is called), though I think we should try to expand that set of points.  Tom suggested possibly doing it periodically when we invoke the QUIT macro, which would include various points in the bytecode interpreter.

> Opening a general discussion about concurrency is something I'd like to do
> soon, but not until I better understand what has already taken place.

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.

Ken