Re: Concurrency, again

[John Wiegley <jwiegley@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2326 bytes --]

>>>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

SM> IOW if we want to take advantage of tens of cores in Emacs, we have to
SM> think very differently. A language with STM or with "communicating agents"
SM> won't cut it, I think.

I can't think of too many cases where existing Emacs Lisp would immediately
benefit from being massively parallel, either. Too much code is written in an
imperative manner (manipulating variables) than a functional one (generating
new values from inputs). If Lars had written much of Gnus using a map/reduce
pattern, I could see it suddenly speeding up if we parallelized those
primitives. But I'm guessing a fair bit of rewrite would be needed to take
advantage of extra cores.

Note too that all of this perceived benefit is still theoretical. We've yet to
answer the main question -- in my mind, the only question when it comes to
whether we should consider including this type of support: Will it solve the
annoyance people have of Emacs blocking when they ask it to do certain things?

Examples of my own, coffee-break inducing moments:

 - Asking for 10,000 back articles in Gnus, with sorting and threading on
 - Applying a keyboard macro to manipulate 1000 file contents in dired
 - Hitting 'g' in Magit in a repository with tons of stashes, pull requests,
   pending changes, etc.
 - Waiting for ERC to replay message logs from ZNC in 20 channels
 - Asking Proof General to check a file that depends on 30 other files

And yet, this list is *about it* for me, and I practically live in Emacs. I'm
not even completely sure yet that solving these would appreciably benefit my
workflow. I don't mind the occasional coffee break.

I just want to make sure we're not try to solve the technical problem just
because it's solvable; we should only solve it if it's a real problem that is
getting in people's way, or is stopping us from doing the Next Cool Thing.

So, thanks to Eli I'm open to considering the concurrency branch for merging.
But I'm also in no hurry whatsoever, and I'd prefer to avoid the extra
complexity if it doesn't actually represent a significant improvement.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]