NS port thread problems

NS port thread problems

[Alan Third]

On Wed, Oct 20, 2021 at 11:05:38AM +0800, Po Lu wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > I don’t think there’s really any way round this other than the massive
> > rewrite the NS port needs to make it handle threads correctly.
> 
> I don't understand the precise problem here (nor do I understand the
> thread code.)  Could you elaborate on what the problem is, and why it
> requires a massive rewrite?  Thanks.

macOS since, I think, 10.14 has required *ALL* GUI work to happen on
the main thread. This is a problem since, if you imagine running:

  (frame-set-width nil 100)

in a thread it will ultimately end up calling ns_set_window_size which
in turn will call "[window setFrame:frameRect display:NO]", which has
to be run in the main thread. ns_set_window_size also calls a number
of other GUI related methods, all of which need to run in the main
thread.

One solution would be to use Objective C "blocks" to run the code in
the main thread, but GCC doesn't support them, so that's out.

Another option is to use a "proxy" to send the messages to the main
thread. I know this works as I've written a proof of concept.

The main problem with that is that most of the functions we have that
will have to send method calls to the main thread have MANY method
calls, so that's a lot of back and forth to and from the main thread.
It seems to me that the better option is to try and simplify the code
so that ObjC classes provide the methods that the Emacsy C code
requires, rather than mixing it all together.

Additionally, I think even calling [NSView window] causes an error, so
any piece of code, that may run outside of the NS run loop, that
accesses an NSWindow MUST be sent to the main thread.

That's quite a lot of the C code in nsterm.

My ultimate plan, which I'm working towards very slowly, is to
introduce an EmacsFrame class that controls the EmacsViews and
EmacsWindows, and provides an API that matches roughly what the Emacs
side expects a frame to do. That's what most of my recent clean-up
work has been working towards.

I do not think that GNUstep has these limitations, so threads may not
be as prone to crash Emacs using it.
-- 
Alan Third

Re: NS port thread problems

[Po Lu]

Alan Third <alan@idiocy.org> writes:

> On Wed, Oct 20, 2021 at 11:05:38AM +0800, Po Lu wrote:

> macOS since, I think, 10.14 has required *ALL* GUI work to happen on
> the main thread. This is a problem since, if you imagine running:
>
>   (frame-set-width nil 100)

> in a thread it will ultimately end up calling ns_set_window_size which
> in turn will call "[window setFrame:frameRect display:NO]", which has
> to be run in the main thread. ns_set_window_size also calls a number
> of other GUI related methods, all of which need to run in the main
> thread.

> One solution would be to use Objective C "blocks" to run the code in
> the main thread, but GCC doesn't support them, so that's out.

I'm aware of this feature, but I don't understand how it will allow for
running code in the main thread.

> I do not think that GNUstep has these limitations, so threads may not
> be as prone to crash Emacs using it.

Interesting, thanks.

Re: NS port thread problems

[Alan Third]

On Thu, Oct 21, 2021 at 08:35:01AM +0800, Po Lu wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > One solution would be to use Objective C "blocks" to run the code in
> > the main thread, but GCC doesn't support them, so that's out.
> 
> I'm aware of this feature, but I don't understand how it will allow for
> running code in the main thread.

You can send a block off to run in another thread. Look up
dispatch_sync and friends.

-- 
Alan Third