[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.
- Re: Concurrency, again, (continued)
- Re: Concurrency, again, Perry E. Metzger, 2016/10/13
- Re: Concurrency, again, Stefan Monnier, 2016/10/13
- Re: Concurrency, again, John Wiegley, 2016/10/13
- Re: Concurrency, again, Stefan Monnier, 2016/10/13
- Re: Concurrency, again, Richard Stallman, 2016/10/14
- Re: Concurrency, again, Stefan Monnier, 2016/10/14
- Re: Concurrency, again, John Wiegley, 2016/10/14
- Re: Concurrency, again, Eli Zaretskii, 2016/10/15
- Re: Concurrency, again, Richard Stallman, 2016/10/15
- Re: Concurrency, again, John Wiegley, 2016/10/15
- Re: Concurrency, again,
Eli Zaretskii <=
- Re: Concurrency, again, Richard Stallman, 2016/10/16
- Re: Concurrency, again, Eli Zaretskii, 2016/10/17
- Re: Concurrency, again, Philipp Stephani, 2016/10/25
- Re: Concurrency, again, Dmitry Gutov, 2016/10/25
- Re: Concurrency, again, Clément Pit--Claudel, 2016/10/13
- Re: Concurrency, again, John Wiegley, 2016/10/13
- Re: Concurrency, again, Ted Zlatanov, 2016/10/14
- Re: Concurrency, again, Michael Albinus, 2016/10/14
- Re: Concurrency, again, John Wiegley, 2016/10/14
- Re: Concurrency, again, John Wiegley, 2016/10/14