>>>>> "SM" == Stefan Monnier 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