Re: Multithreading, again and again

[Dave Abrahams <dave@boostpro.com>]

on Sat Oct 22 2011, Tom Tromey <tromey-AT-redhat.com> wrote:

>>> Anyway, I think the single-thread event driven approach is better for
>>> Emacs, like Node.js and other languages do.
>
> Yes, maybe so, but I think there are two reasons concurrency is
> desirable.
>
> One reason is that, in practice, the current event-driven approach
> sometimes falls down.  E.g., ERC can time out when something in Emacs
> blocks too long.  These are bugs, and worse, won't be immediately fixed
> by concurrency -- but at least could be, in the long run, in a permanent
> way.
>
> The other reason is that concurrency makes it easier to convert code to
> run in the background, without a need for a drastic rewrite.  I think
> Gnus is the prime candidate here -- make 'g' work in the background by
> just inserting a (make-thread) at the appropriate juncture.  Rewriting
> arbitrary code in the process-filter style is too much work, it seems to
> me.

Exactly my point.  The current facilities for doing concurrency are too
hard/unnatural to use for this kind of job.  If they were easier, it
might be more practical to offload more work to another process, and
more packages would do it.  At least until the cost of sending the
necessary s-expressions between processes becomes prohibitive, this
seems like a natural way to go that avoids making Emacs incredibly
brittle as I expect it would be if we started trying to run
single-threaded code in multiple threads.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com