emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Concurrency, again


From: Eli Zaretskii
Subject: Re: Concurrency, again
Date: Sun, 16 Oct 2016 09:40:09 +0300

> From: Richard Stallman <address@hidden>
> CC: address@hidden, address@hidden
> Date: Sat, 15 Oct 2016 18:03:15 -0400
> 
>   > That's what the code on the "concurrency" branch of the Emacs
>   > repository does -- except that (1) it doesn't allow you to create
>   > special asynchronous programs at all, and (2) it is capable of
>   > switching to another ordinary Lisp program when the current one is
>   > waiting for something (e.g., keyboard input or subprocess output), or
>   > explicitly yields to another.
> 
> (2) is a source of possible conflicts between various programs; I
> suspect that lots of bugs could result.

I believe Tom Tromey, who wrote the code, took precautions so that
such bugs won't happen "by design".  Some design principles and
limitations towards this end are:

 . thread switching happens either when Emacs is waiting for input, or
   by explicit request of a thread to yield, or when a thread blocks
   because it waits for a mutex or to join another thread

 . global variables are shared between all threads, but local variable
   let-bindings are specific to the thread that made them

 . each thread has its own current buffer and its own match data

 . by default, a process is locked to the thread that created it,
   which means output from the process can only be accepted by that
   thread; however, a Lisp program can specify to which thread a
   process is locked, or unlock the process, in which case any thread
   can accept its output.  In any case, once some thread starts
   waiting for output of a process, the process becomes temporarily
   locked to that thread, so only that thread will eventually receive
   the output, unless it yields.  If a thread exits, all its processes
   are unlocked.

> Are such bugs why the "concurrency" branch is not ready?

We don't really know, because the branch was never seriously used.

> To limit concurrency to specially designated programs
> might make it easier to avoid those problems.  Those programs
> could conceivably be written following certain special rules
> that avoid the bugs.

That's what the branch does: if a Lisp program doesn't create any
threads, it will run normally, as in today's Emacs, using a single
main thread.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]