[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Concurrency, again
From: |
Stefan Monnier |
Subject: |
Re: Concurrency, again |
Date: |
Wed, 12 Oct 2016 15:43:12 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2.50 (gnu/linux) |
>> I urge you to have a look at the sources on the concurrency branch. There's
>> no threading, in the usual sense of that word: at any given time, only a
>> single thread is running. It's not at all what you seem to be imagining.
>> Think about idle timers that run without your having to do anything to start
>> them: that's what we have there, in a nutshell, plus a few niceties.
> More akin to green threading then?
Right. It does introduce the possibility to have new interleavings, so
new bugs, but 99% of the bugs it uncovers should be reproducible (at
least in theory; tho maybe only in convoluted circumstances) in the
non-concurrent branch as well.
> It's interesting to note how many people agree with caution, or don't claim to
> need threading, vs. those calling for its inclusion. I know many users who
> don't want Emacs locking up on them. This is the problem that needs solving.
> Is threading in Emacs Lisp the answer? I still don't know.
I think there are many different needs/desires related to "concurrency".
A typical one (for me anyway) is:
- I want to use Gnus, but I want to be able to edit files while Gnus
consults the IMAP server to see if there are new messages, or while
Gnus is waiting for the damn NNTP server to answer.
Currently I solve this problem by running Gnus in a separate Emacs
session (i.e. I basically always have 2 Emacs processes). I lived
with it for the last 20 years, so it's not that bad, but
it's inconvenient.
The concurrency branch should be able to solve this problem.
We could probably solve this problem also using a cps-translation like
the one in generator.el, to take the synchronous code using
accept-process-output, and turn it into code which runs
asynchronously, from the process filters&sentinels. It's likely to be
somewhat brittle, tho.
- I want semantic-mode to scan my buffers in the background and to scan
several buffers at the same time, to make use of my 8 cores.
The concurrency branch doesn't really try to solve this problem.
I'm not sure what's the best way to solve this problem, and I don't
even know what would be a "simple" way to solve this problem.
-- Stefan
- Re: Emacs Lisp's future, (continued)
- Re: Emacs Lisp's future, Eli Zaretskii, 2016/10/09
- Re: Emacs Lisp's future, John Wiegley, 2016/10/09
- Re: Concurrency, again (was: Emacs Lisp's future), Eli Zaretskii, 2016/10/10
- 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 <=
- 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, 2016/10/12
- 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