Re: SDL terminal type

Lina Bhaile <[email protected]> writes:

> Richard Stallman <[email protected]> writes:
>
>>   >  As I understand it, separating into multiple processes is a (the?) main
>>   > *goal* of the EDSP proposal. It has the benefits of both allowing to take
>>   > more advantage of parallelism in modern hardware, and it also works
>>   > around a common issue where both Emacs and the UI library want (in
>>   > some cases, insistently) to control the "main loop".
>>
>> Is this of any use on machines that don't have GPUs?
>>
>> (We must not let GPUs impose their "needs" on the design of Emacs, not
>> while GPUs continue to be fundamentally unjust.)
>
> Theoretically, as Chad mentioned, a multi-process architecture could
> increase Emacs' speed on multi-processor machines, which work with free
> software. However it may not result in any particular benefit, as the
> two processes would need to synchronise with each other.

What is often not appreciated properly in conversations of this kind is
that for performance there is no meaningful difference between running
the toolkit in a separate process, and doing so in a separate thread.
If anything, it ought to be slightly more efficient to do the latter, by
eliminating the IPC boundary between the two components.  In Linux
systems a process and a thread are one and the same thing, the only
difference being that the latter shares an address space with certain
other threads.  Therefore the only justification for running the toolkit
in a separate process would be the actual impossibility of running
Emacs's main loop in a separate thread from the UI.

I feared that this would be the case with the Android port, but it was
not in practice, so that now, in the Android port, the UI thread and
Emacs's input loop will run independently of each other, and synchronize
where it is required to exchange data with the toolkit.  The same
applies to the MS Windows and Haiku support.

Now, I may well be mistaken, but anecdotally it seems that none of these
ports are intrinsically more performant than the ports where the
toolkit's event loop is controlled by Emacs.  In the X-based ports this
is done because it is convenient and harmless, and (in GTK's case) also
because Glib provides facilities for doing so, however unreliable they
may be.  In the NS port it is implemented much less reliably, but
nevertheless it does not produce any performance issues, and in Carbon
Emacs the Mac OS event loop is controlled by the toolkit and Emacs
itself runs in another thread, just as on Android.  Many of you would
also be surprised to learn what amount of processing is done by video
games in the main thread where frames are rendered.

On account of the sheer frequency at which proposals almost
word-for-word identical to this one are made alone, I urge everyone not
to insist upon separating the GUI from the event loop as a panacea for
performance problems, or as a particularly difficult requisite of using
whatever GUI toolkit you think will improve Emacs.  The sources of the
problems are elsewhere, and at all events the solution being proposed
has already been put into practice in three ports, and does not yield
the improvements it is said to bring.