- * Basically, you must ensure there's some fixed upper bound on the amount of
- * computation that can occur before a glk_tick() (or glk_select()) occurs. In a
- * VM interpreter, where the VM code might contain an infinite loop, this is
- * critical. In a C program, you can often eyeball it.
+ * <note>
+ * <para>Captious critics have pointed out that in the sample program
+ * <filename>model.c</filename>, I do not call glk_tick() at all. This is
+ * because <filename>model.c</filename> has no heavy loops. It does a bit of
+ * work for each command, and then cycles back to the top of the event loop.
+ * The glk_select() call, of course, blocks waiting for input, so it does all
+ * the yielding and interrupt-checking one could imagine.
+ * </para>
+ * <para>Basically, you must ensure there's some fixed upper bound on the
+ * amount of computation that can occur before a glk_tick() (or glk_select())
+ * occurs. In a VM interpreter, where the VM code might contain an infinite
+ * loop, this is critical. In a C program, you can often eyeball it.
+ * </para>
+ * <para>But the next version of <filename>model.c</filename> will have a
+ * glk_tick() in the ornate printing loop of <function>verb_yada()</function>.
+ * Just to make the point.
+ * </para>
+ * </note>