Re: Threads in emacs implementation

[Ken Raeburn]

On Jun 6, 2005, at 22:22, Denis Bueno wrote:
> Having said that, my question is, has thought been put into
> multithreading parts of Emacs? Or exposing a rudimentary threading API
> to Emacs Lisp? This could easily devolve into a war about threading
> apis, but, just support some simple subset of pthreads would work.

I've thought about it, yes.

As Miles said, there's a lot of global state, and lots of code that 
doesn't expect threading issues.  Indeed, the basic Lisp system itself 
would need changes to deal with any sort of preemptive threading 
system; dynamic bindings are currently implemented by overwriting a 
symbol's value, and keeping track on the stack of what value needs to 
be restored later.  Garbage collection also gets more interesting when 
multiple threads are manipulating Lisp objects at a time.  (One could 
go with fully cooperative threads, but then you still have to rewrite 
all your I/O to be non-blocking, you lose any benefits of 
multi-threading in third-party library code that might block, can't 
take any advantage of multiple CPUs, etc.)

For various reasons, I decided to put my attention about three years or 
so ago into a somewhat different project -- making it possible to run 
Emacs with the Guile interpreter tied into the Lisp system.  Guile -- 
GNU's Ubiquitous Intelligent Language for Extension -- is the GNU 
Project's Scheme implementation, intended to be a general extension 
language for the GNU Project.  Scheme is Lisp-like in some ways, 
different in others; in particular, Scheme uses static scoping, so Lisp 
dynamic bindings are an interesting part of the issue.  But there are 
people working on making Guile be able to handle Emacs Lisp, and there 
already is pthread support in Guile.  So my thinking is, if the Emacs 
Lisp engine can be made to operate on Guile objects (including, for 
example, a new Guile object type that represents an Emacs buffer, which 
is a Lisp type now), and these other people find ways to deal with 
threads and dynamic scoping, then we've made a lot of progress not just 
towards the possibility of multiple threads in Emacs, but also towards 
having GNU's "ubiquitous extension language" available in what's 
probably GNU's most commonly extended (and most extensible) program.

(There would be other effects also, like having one *massive* 
application stress-testing the heck out of the Guile allocator and GC 
system.  Might be good for Guile in the long run, but I suspect the 
initial performance might not be as good as what Emacs has already; 
then again, I might be pleasantly surprised.  There's a research 
project out there on translating Lisp to Scheme and determining when 
you might be able to optimize out the whole dynamic-binding mess and 
use local values, which may translate to more efficient code.  If Emacs 
buffers can be made into an independent object type, perhaps other GNU 
programs can incorporate them via Guile extensions.  Guile has compiled 
regular expressions as their own type; wouldn't it be nice if Gnus 
article splitting could cache all of the compiled regular expressions 
it uses even when GC runs, instead of just some number compiled in to 
search.c?)

I started doing some work on isolating the Lisp system from the rest of 
Emacs -- removing some assumptions here and there about how Lisp 
objects were constructed, that sort of thing.  But then I got 
sidetracked with pesky things like work, wow, probably a couple of 
years ago now, and wasn't able to make much progress for a long time.  
(Unicode branch guys -- I'm sorry I never got that merge to your branch 
done that was discussed back then, but by the time anyone got back to 
me saying "yes", I was already too hosed to pay attention.)  I've 
managed to get some more time to put into it recently, but (a) I've 
changed jobs and need to re-file some of the paperwork for donating 
code, and (b) there's been talk of some kind of code freeze or at least 
feature freeze, though I haven't been able to keep up on the mail quite 
enough to know what the state of things is.  So, I'm not sending in any 
code changes yet.  (And haven't got a lot of them yet anyways.)

That sort of work is relatively easy (even if sometimes spread through 
lots of code -- the widespread changes are usually simple and 
mechanical), and contributes in some ways towards keeping the code 
cleaner outside of the guts of the Lisp engine itself.

Should we go all the way and actually replace the Lisp object 
representation with something based on Guile?  Some people say yes, 
some people say absolutely not.  Some think we should be rewriting 
Emacs into some other language.  Me, I just want to get something that 
works, maybe fix some bugs in Guile and in Emacs that might be found in 
the process, and then see where things stand...

Even if that happens, I have only put a little thought into what the 
Emacs Lisp interface for threads would probably look like.  Actually, 
unless someone comes up with a more friendly wrapper package, I suspect 
the interface would look a lot like the Scheme interface in Guile -- 
thread creation, mutex locks, condition variables, etc.  Plus, I would 
guess, locks in objects like buffers, windows, and frames to keep them 
from getting corrupted.  Message passing, work queue management, and so 
forth could be built on top of the primitives without too much 
difficulty, in either Lisp or Scheme.  I think I'd be more concerned 
about the UI -- we probably don't want two threads vying for user input 
and stealing characters from one another or something.  And, of course, 
all that global state Miles was talking about...

(Note, too, that once you start using pthreads, you get new 
restrictions on maximum stack depth, things like that; it can't grow 
unbounded.  That translates directly into a limit on the depth of Lisp 
function calls, not by number, but by C stack frame size.)

> The background for my question: In Gnus, certain network operations
> often take a long time -- sometimes I don't want to check my email
> when it prompts me for a password, but I hit Return anyway, causing
> Emacs to visibly hang for a minute or two. Sometimes whatever server
> Gnus wants is down (or DNS is down, or whatever), and it 'hangs' until
> it's timed out. This downtime is in many cases at least long enough
> that I could profitably be doing work in other Emacs buffers.

This, in fact, was my motivation for thinking about it.  But, I was 
also doing a little hacking on Guile at the same time, and, well, I'm 
sure some would say it was all downhill from there....

Ken