Creating a separate GUI thread for NS

Creating a separate GUI thread for NS

[Alan Third]

Cocoa and GNUstep have this thing called a ‘run loop’, that handles
all the GUI windows and IO and so on. At the moment we have a
complicated system where we run it from ns_select, while the real
select runs in a separate thread, and we then synchronise them with
message passing.

There are some unfortunate side effects like not being able to update
the frame while it’s being resized because we can’t break out of the
run loop to run redisplay.

The sensible thing to do would be to move the run loop to its own
thread. I believe we do something similar on Windows.

The problem is that Cocoa insists the run loop *must* be run on the
main thread, and Emacs also insists that *it* runs on the main thread.

Is there a way to get Emacs to run on a child thread? Is it just a
case of resetting main_thread_id in sysdep.c?

Thanks!
-- 
Alan Third

Re: Creating a separate GUI thread for NS

[Eli Zaretskii]

> Date: Sat, 27 Jan 2018 11:14:57 +0000
> From: Alan Third <alan@idiocy.org>
> 
> The sensible thing to do would be to move the run loop to its own
> thread. I believe we do something similar on Windows.

On MS-Windows, the separate thread runs the GUI input message pump.

> The problem is that Cocoa insists the run loop *must* be run on the
> main thread, and Emacs also insists that *it* runs on the main thread.
> 
> Is there a way to get Emacs to run on a child thread? Is it just a
> case of resetting main_thread_id in sysdep.c?

You should consider which thread gets the signals (or their
equivalents).  Emacs currently assumes its the main thread, and that's
what you see in sysdep.c.  But some other traces of this assumption
are elsewhere, so you should carefully review any code that is related
to signals.

Does the text-mode session on NS use SIGINT for C-g?

(Caveat: I know nothing about NS.)

Re: Creating a separate GUI thread for NS

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

Eli Zaretskii <eliz@gnu.org> schrieb am Sa., 27. Jan. 2018 um 12:34 Uhr:

>
> > The problem is that Cocoa insists the run loop *must* be run on the
> > main thread, and Emacs also insists that *it* runs on the main thread.
> >
> > Is there a way to get Emacs to run on a child thread? Is it just a
> > case of resetting main_thread_id in sysdep.c?
>
> You should consider which thread gets the signals (or their
> equivalents).  Emacs currently assumes its the main thread, and that's
> what you see in sysdep.c.  But some other traces of this assumption
> are elsewhere, so you should carefully review any code that is related
> to signals.


Could we switch signal processing to a simpler model, such as a background
thread and sigwait?

[-- Attachment #2: Type: text/html, Size: 1058 bytes --]

Re: Creating a separate GUI thread for NS

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sun, 28 Jan 2018 17:00:53 +0000
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> Could we switch signal processing to a simpler model, such as a background thread and sigwait? 

How would that work with C-g on TTYs, which generates SIGINT, and
should eventually cause a longjmp to top level?

Same question regarding SIGIO, which is used on X-based systems for
input.