+/**
+ * glk_select_poll:
+ * @event: Return location for an event.
+ *
+ * You can also inquire if an event is available, without stopping to wait for
+ * one to occur.
+ *
+ * This checks if an internally-spawned event is available. If so, it stores it
+ * in the structure pointed to by @event. If not, it sets
+ * <code>@event->type</code> to %evtype_None. Either way, it returns almost
+ * immediately.
+ *
+ * The first question you now ask is, what is an internally-spawned event?
+ * glk_select_poll() does not check for or return %evtype_CharInput,
+ * %evtype_LineInput, %evtype_MouseInput, or %evtype_Hyperlink events. It is
+ * intended for you to test conditions which may have occurred while you are
+ * computing, and not interfacing with the player. For example, time may pass
+ * during slow computations; you can use glk_select_poll() to see if a
+ * %evtype_Timer event has occurred. (See <link
+ * linkend="chimara-Timer-Events">Timer Events</link>.)
+ *
+ * At the moment, glk_select_poll() checks for %evtype_Timer, %evtype_Arrange,
+ * %evtype_Redraw and %evtype_SoundNotify events. But see <link
+ * linkend="chimara-Other-Events">Other Events</link>.
+ *
+ * The second question is, what does it mean that glk_select_poll() returns
+ * <quote>almost immediately</quote>? In some Glk libraries, text that you send
+ * to a window is buffered; it does not actually appear until you request player
+ * input with glk_select(). glk_select_poll() attends to this buffer-flushing
+ * task in the same way. (Although it does not do the <quote><computeroutput>Hit
+ * any key to scroll down</computeroutput></quote> waiting which may be done in
+ * glk_select(); that's a player-input task.)
+ *
+ * Similarly, on multitasking platforms, glk_select() may yield time to other
+ * processes; and glk_select_poll() does this as well.
+ *
+ * The upshot of this is that you should not call glk_select_poll() very often.
+ * If you are not doing much work between player inputs, you should not need to
+ * call it at all.
+ *
+ * <note><para>
+ * For example, in a virtual machine interpreter, you should not call
+ * glk_select_poll() after every opcode.
+ * </para></note>
+ *
+ * However, if you are doing intense computation, you may wish to call
+ * glk_select_poll() every so often to yield time to other processes. And if you
+ * are printing intermediate results during this computation, you should
+ * glk_select_poll() every so often, so that you can be certain your output will
+ * be displayed before the next glk_select().
+ *
+ * <note><para>
+ * However, you should call glk_tick() often — once per opcode in a VM
+ * interpreter. See <link linkend="chimara-The-Tick-Thing">The Tick
+ * Thing</link>.
+ * </para></note>
+ */
+void
+glk_select_poll(event_t *event)
+{
+ g_return_if_fail(event != NULL);