I lay out a model for implementing a two-threaded Glk library – one thread for the user interface, one for the virtual machine (Glulx). I used this when implementing Glk for iOS.
eblong.com/zarf/glk/threading-notes.html
CocoaGlk tries to do this but has some bugs. So I figured I should write up my plan.
To clarify: this isn’t something that game authors have to worry about, or will even notice. (Except for interpreter bugs if it’s done wrong. 
This is a technique for implementing an interpreter which runs smoothly on a modern GUI OS.
Do you think this technique would help improve performance on portable interpreters, like iFrotz, on computing-heavy games that might otherwise run slower? Or that rely on some fancy multiple-window trickery for vital/optional visual effects which take their time to be set up?
I assume the answer would be “yes” since you did this yourself on your own iGlk thing, and you wouldn’t do that if there wasn’t an advantage. But I prefer to ask rather than assume.
This improves responsiveness, not performance.
If a command takes half a second to process, you still won’t see the output until after half a second. The difference is that during that half-second, you’ll be able to scroll, select text, resize the window if the UI has windows, etc.
This is particularly important on mobile, because the app is the entire display. If it’s not responding, it feels like your entire phone has frozen up for that interval, which is unpleasant.
Ok. Thanks for taking the time to clear that up for a non-technical, non-interpreter author layman like myself. 