Re: "concurrency" branch updated

[Ken Raeburn]

> 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