Re: Embedded lua and yielding to the application run loop (macOS)

[Eric Wing <ewmailing@...>]

Manually pumping the event loop on macOS can work in limited cases,
but can/will break down if your application uses/interacts other
system frameworks that depend on the native event loop. Apple has
private implementation details in their event loop pump which can't be
recreated through public APIs and some of their own implementations
seem to depend on these things (or have some kind of implicit
assumptions). For example, things with modal windows, file dialogs,
and menu bar interaction may no longer work correctly. I remember a
very old bug where Game Center just wouldn't work.

So generally speaking, you should not manually pump the event loop on
Apple. If you do, it should be for a very limited, and very specific
time, and your app should be avoiding a lot of native AppKit/system
related features, and your application should resume using the normal
Apple runloop.

Also remember that, when you manually pump the event loop, other event
responder code that may have been written elsewhere may completely
miss seeing the events if they occurred while you were manually
pumping the event loop.


Also, a note about the main thread...this is probably the correct
thing in general. If you are calling any AppKit (GUI) APIs, they must
be on the main thread. My impression of Hammerspoon was that this is
what it is doing, so the design of it being on the main thread is the
correct one. If you want to use Lua on a background thread, make sure
that that thread never calls AppKit APIs or anything else that is not
background-thread-safe on Apple.


Personally, I've seen too many projects get into trouble manually
pumping the event loop and using background threads incorrectly on
Apple. (Coincidentally, I recently got contracted to help fix these
class of problems in the Mac port of a very popular game.)

Since coroutines have been mentioned here, they sound like a much
better path to go down to me.

-Eric