Philipp Stephani <
address@hidden> schrieb am Do., 24. Mai 2018 um 19:46 Uhr:
> 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.
The w32 build has a similar problem, and it solves it by setting up
message queue between the main and the input threads. Messages are
sent between the two threads when needed, and the Windows native
messages are used in the opposite direction. So when one thread needs
something done by the other thread, it sends the appropriate message,
waits for a response, then continues (and sometimes it doesn't have to
wait for any response, it depends on the case).
Can NS use some similar machinery?
Most likely yes (because UI toolkits always work that way). The to-be-written GTK+ terminal should use the same mechanism.
What's the "input thread" in the Windows implementation? At least on macOS the UI thread (i.e. the thread that creates windows and handles events) must be the main thread, which means the Lisp interpreter thread(s) should become background threads.
However, the documentation also says "The main thread is the one blocked in the run method of NSApplication", which seems to indicate that the "main" thread doesn't actually have to be the same thread that the main function runs in.