Re: What's the problem? (Was: Are there plans for a multi-threaded Emacs?)

[Ted Zlatanov]

On 08 Dec 2003, address@hidden wrote:

> Ted Zlatanov <address@hidden> writes:
> 
>> Note I don't claim these can't be rewritten in a concurrent
>> fashion.  I simply gave examples that could stand to be improved.
>> The majority of examples are in Gnus, because that's the Elisp
>> application I know best.
> 
> Have you already done the obvious thing of setting gnus-asynchronous
> to a non-nil value?  That's the least one would expect from somebody
> that wants parallelism that badly.

I'm fairly familiar with Gnus.  gnus-asynchronous helps pre-fetch
articles, which is nice but tangential to the issues raised here.

> You can't just throw in parallelism and hope that things will work
> out somehow.

I was aware of that fact.

>> - Gnus mail retrieval, summary thread building, registry lookups
> 
> Most of those can be controlled with gnus-asynchronous and
> subordinate variables.

Only pre-fetching of articles, which is not the problem most of the
time.

>> - independent hashtable lookups and calculations in parallel would
>>   be a very nice improvement in themselves,
> 
> Why?  What time-critical code performs them frequently?

1) It's hard to write code that does parallel calculations when there
   is no API and no internal support.  Most current Emacs code would
   not use parallel calculations because if was not written with that
   in mind.  As you appropriately mention above, you can't just throw
   in parallelism, applications have to be written for it.

2) The improvement is incremental, for the user's benefit.  Emacs
   will not gain speed or simplicity, but users will gain improved
   responsiveness and will be happier using Emacs.

> If you want to afford a separate binding stack for every thread,
> this also means that every _read_ _access_ to a symbol must run via
> the thread's binding stack instead of just using the stack whenever
> the a binding _changes_.

So you're saying that it will slow down Emacs by using memory and CPU,
to manage the thread-local binding stack, correct?  I agree.

Ted