Re: What's the problem?

[Simon Josefsson]

Luke Gorrie <address@hidden> writes:

> Ted Zlatanov <address@hidden> writes:
>
>> I'm convinced, based on the many posts made, that the best way to
>> approach multithreading is slowly and incrementally.
>
> What's the biggest problem that threads are intended to solve?
>
> Is it that it's too hard or ugly to write concurrent programs in Elisp
> today?

It is too hard and ugly to write concurrent programs in elisp today,
but that is not the only reason.

> If so, what are some examples of bad cases that cause users pain and
> _really_ can't be rewritten neatly and with happy concurrency
> properties in plain old Elisp after some rethinking?
>
> (Sorry if I have missed definitive examples earlier in the thread!)
>
> 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.

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.

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.  (address@hidden)