What I am worried about are cases where this becomes the default game loop:
do
{
partial_calculation();
glk_select_poll_all(event);
}
while (event->type != evtype_None);
Once the calculation finishes, the loop will continue aggressively polling the OS for events. Absent timers, UI events are unlikely to fire more than once every 10-20 ms, so this becomes a tight loop that spikes the CPU and makes the battery cry. I realize that this isn’t what you intend, but there’s nothing to stop careless game authors or extension writers from abusing this call.
Right now you can’t write a functional game that does this, because in order to actually receive UI events, you need to call glk_select() which will yield CPU time until an event comes in.
I would point you to the way sound notify events work, since I think they are a useful example of a long-running procedure that may end at any time, even during user input. However, I don’t think they work particularly well as it stands, at least not in Gargoyle.
In a multi-threaded library, a notification event can be generated in the background, can even be queued up for dispatch, but the thread that needs to return the event to the VM - the one that called glk_select() - is suspended until a UI event comes in. Once that occurs, the thread wakes up, processes the input, checks the event queue, sees the sound notification, and returns it to the VM.
To see where this breaks down, imagine a sequence of sound effects chained together, e.g. a voice-acted conversation. You don’t want to hold the player hostage, so you call glk_select() so that they can move around, examine things, or even initiate a different conversation - in technical terms, you are receiving and processing line events while the sounds play.
Because of the way the OS suspends the main thread, there will almost always be a delay between the end of one sound and the start of another. The delay is controlled by the user - if he presses a key, clicks the mouse, or resizes the window, the UI thread will unblock, the sound notification will be dispatched, and the VM will play the next one.
This isn’t really a big deal for background, ambient music where you can just fade out to silence and the user may not be consciously aware of when it starts or stops. But it would be really weird for NPC barks.
Hmmm. Even with callbacks / interrupts into the VM, you’d need to be able to unblock the suspended thread somehow. And if that can be done, it probably should be done with sound notify events today. In other words, it’s a library bug.
So given that glk_select() already returns all events of interest, and does it in a way that doesn’t lead to busy-waiting, it seems like the ideal solution would be to somehow pass off the computation to Glk and wait for the evtype_Compute event to tell you when it’s finished. No?