Re: What's the problem?

[Juri Linkov <juri@jurta.org>]

Simon Josefsson <jas@extundo.com> writes:
> Luke Gorrie <luke@bluetail.com> writes:
>> People are writing concurrent programs in Elisp today. Most programs
>> interacting with external processes and sockets do so without blocking
>> Emacs. Can't we all just do the same?
>
> No.
>
> I believe several examples have been given already, but the most
> prominent I notice frequently is generating summary buffers in Gnus.
> This is CPU bound.  Most of the time is NOT spent waiting from network
> IO, even for 64kbps users, if you profile large groups.  It is spent
> traversing internal data structures, sorting and filtering the
> headers.  If this is done asynchronously, it would still lock up
> Emacs.

Many CPU bound tasks can be improved by memoizing computation results.
Since most cited here example is generating summary buffers in Gnus,
I want to note that this particular problem can be solved by storing
computed thread trees in files similar to `.marks' and `.overview'.
To keep track of computed results input parameters should be stored
along with computed data.

> Another example is getting new mail in Gnus.  This is probably more
> network bound than CPU bound, but doing it asynchronously would still
> lock up Emacs completely for many seconds, which is unacceptable.  If
> you use Gnus as a offline reader, getting new mail may take minutes.

Many tasks can be performed by external processes.  Getting new mail
shouldn't lock up Emacs when done by an external program like movemail.

> The most interesting examples doesn't exist, though, because people
> have simply not implemented some ideas because of a lack of
> multi-threaded support in Emacs.  If developers realized you could
> have a background thread in Emacs doing various calculations and
> giving the user feedback or interaction opportunities once in a while,
> I'm sure we'd see many interesting add-on packages.  (SETI@Emacs?)

I believe too that implementing multi-threaded support in Emacs
will create more possibilities for new and existing Emacs packages,
for instance, for such computation-intensive tasks as rendering
markup languages and for creating a better web browser in Emacs.

-- 
http://www.jurta.org/emacs/