Threading and the NS port

[Alan Third]

On Thu, May 28, 2020 at 02:48:42PM +0200, Robert Pluim wrote:
> >>>>> On Fri, 22 May 2020 22:47:25 +0200 (CEST), Alan Third <alan@idiocy.org> 
> >>>>> said:
> 
>     Alan> No great surprises that this function is related to the NS run loop,
>     Alan> which handles IO.
> 
>     Alan> I'm convinced that most of these crashes centred around tramp and 
> the
>     Alan> menu bar and so on are best fixed by separating the NS GUI code 
> into a
>     Alan> separate thread, but it's a pretty large job, and I only have half 
> of
>     Alan> an implementation.
> 
> Is this on a branch somewhere?

I've pushed it up to scratch/ns/next on savannah. The most recent
commit breaks the GUI, iirc, but shows roughly what I was thinking of
doing. I think if you remove it the branch should build and run OK
without crashing if GUI things are done from a non-main thread.

The last commit is actually from a previous attempt at threading the
whole thing.

The general plan was to create a new EmacsFrame object that all calls
to frame related stuff (GUI code) goes through. This isn't required,
but I feel the EmacsView object is somewhat overloaded with methods at
the moment and I was going to have to add a whole bunch of new ones.

The EmacsFrame methods are called through an NSProxy object which will
send the method calls to the main thread where they'll be run within
the NS run loop. This makes some things run asynchronously, so a fair
bit of the code is attempting to work around that fact.

The last commit attempts to run the GUI code in a separate thread.
Cocoa insists that GUI code has to be run from the main thread, so I
followed the Mac port's lead and have given main() in emacs.c another
name so it can be run as a thread. IIRC there are some other bits and
pieces that are done to try and make sure it picks up the right
signals and so on.

Additionally the GUI code has to be able to run code within the Emacs
main thread, so there's a "sendEmacsEvent" method that is used to
package up input events and sent to a queue where they're picked up
in, I think, ns_read_socket. I wrote this specific code a year ago now
or something, so I'm a little hazy on how it works without looking
back over it.

Now, that doesn't work. I'm not sure how much works needs to be done
to get it working, I just tried applying the old patch on the off
chance it would work, and it also gave me a base to work from, because
sendEmacsEvent and co worked when I tried this before.

I can see that renaming main() could also be controversial.

This also probably won't cleanly rebase on top of current master
because there have been some changes to frame resizing code on master
(we'll want to take them over to this branch, ultimately).

I have no idea if any of this code is worth bothering with. There are
probably better ways of doing things. Some of the problems I'm using
NSProxy to work around could be solved by using Objective C blocks if
they were available, but they're not supported on GCC (or GNUstep)
yet.
-- 
Alan Third