[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Concurrency, again
From: |
Perry E. Metzger |
Subject: |
Re: Concurrency, again |
Date: |
Wed, 12 Oct 2016 17:33:14 -0400 |
On Wed, 12 Oct 2016 23:20:21 +0200 S__ren Pilg__rd
<address@hidden> wrote:
> > One possibility: move to a multiple processes paradigm where each
> > buffer has an associated process, and global variable values are
> > propagated via message passing to a master process. Think Hoare's
> > CSP or Go or Erlang for precedents, though perhaps with more
> > sugaring to make it easy for Emacs users to not think much about
> > global state.
> >
> > This sort of model might be especially important if Emacs starts
> > being used as a serious web browser by lots of its community,
> > given how much CPU modern browsers can eat.
> >
>
> The thing is all current code expects to be able to access any
> buffer they like without interferrence from other code.
> So to make this new model work we would need to support both
> paradigms. If any "old-style" code started execution, by being
> called by a function or from a timer, then the entire world would
> have to halt so the old-style code could execute with its
> assumption of sequential access.
Well, the code expects to *access* buffers, but it doesn't expect to
interact with other executing code. So for "new" code, you would need
to allow code to be able to get to a buffer's contents by some
protocol (possibly even transparent to that process), but it need not
(necessarily) have low level shared data structures the way a
pthreads-like model allows.
I have to admit I haven't thought through all the implications here,
that was an impulse post on my part and I somewhat regret making it
without thinking longer. OTOH, I've become fairly convinced over time
that what is preferable are paradigms where there is zero shared low
level state between executing processes. You just lose all your hair
otherwise yanking it out when you hit bugs.
That said, given the fact that Emacs concurrency would have to evolve
from the current way of doing things, it might be completely
infeasible to implement such a paradigm.
> And then each "new-style" code currently executing would have to
> "finish" its execution and somehow mark that now its buffer and
> bufferlocal variables are in a safe state for the old-style code to
> execute.
> When all current new-style code is marked "safe" then the old-style
> code can execute and when done emacs can continue execution of all
> the new-style code.
> Does this make sense?
That's certainly one possible way of doing things that would allow
migration to a new paradigm without breaking old code.
Concurrency is a giant tarpit of subtleties. :(
Perry
--
Perry E. Metzger address@hidden
- Re: Concurrency, again, (continued)
- Re: Concurrency, again, Paul Eggert, 2016/10/10
- Re: Concurrency, again, Stefan Monnier, 2016/10/12
- Re: Concurrency, again, raman, 2016/10/12
- Re: Concurrency, again, John Wiegley, 2016/10/12
- Re: Concurrency, again, Eli Zaretskii, 2016/10/12
- Re: Concurrency, again, John Wiegley, 2016/10/12
- Re: Concurrency, again, Eli Zaretskii, 2016/10/12
- Re: Concurrency, again, Stefan Monnier, 2016/10/12
- Re: Concurrency, again, Perry E. Metzger, 2016/10/12
- Re: Concurrency, again, Søren Pilgård, 2016/10/12
- Re: Concurrency, again,
Perry E. Metzger <=
- Re: Concurrency, again, Stefan Monnier, 2016/10/12
- Re: Concurrency, again, John Wiegley, 2016/10/12
- Re: Concurrency, again, Eli Zaretskii, 2016/10/13
- 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