Re: Should this package be included into the NS port?

[Alan Third]

On Wed, May 23, 2018 at 06:26:14PM +0300, Eli Zaretskii wrote:
> > From: Nick Helm <address@hidden>
> > Date: Wed, 23 May 2018 17:11:35 +1200
> > 
> > > In an ideal world (and I believe the Mac port has gone this way) we
> > > would put the NSApp run loop in one thread, and Emacs lisp in another
> > > and let them communicate with each other asynchronously. This wouldn’t
> > > solve everything, but it would make some of our problems easier.
> 
> FWIW, that's what the w32 port does.
> 
> > > We can’t easily do that, though, as the inter‐thread communication
> > > systems provided in Objective‐C are either a pain to implement with
> > > complex types like Lisp_Object, or aren’t compatible with GCC and/or
> > > GNUstep (Grand Central Dispatch).
> 
> Why do you need to have the communications between the threads be in
> terms of Lisp objects?  In the w32 port, they communicate in C
> objects, and the communications pipe is the read_socket_hook.  So in a
> nutshell, the GUI event thread sends input to the Lisp interpreter as
> if it was the other end of a socket through which window-system
> events, including keyboard, mouse, and everything else, are coming.

The NS port is similar, it executes the NS run loop within
ns_read_socket, and it sends events to the Lisp interpreter.

The main problem I have is things coming in the opposite direction. I
don’t know if W32 is the same, but we can only run GUI related code in
the main thread. If we separate the Lisp thread and the NS run loop
thread, then code called from Lisp can’t directly interact with the NS
GUI code, it has to be dispatched to the NS run loop thread.

If we do this we’ll have to use performSelectorOnMainThread, which
calls a method or function on the main thread, but only allows you to
pass a single parameter. I believe it’s possible to serialise multiple
arguments into a single one, but I’ve no idea if that’s practical.

I think this is possible, but will probably require a fair amount of
work.

It’s also possible I’m over‐complicating this. I feel rather out of my
depth.

-- 
Alan Third