(v13) Timing

This page applies to Harlequin v13.1r0 and later; and to Harlequin MultiRIP but not Harlequin Core.

The most important restriction applied to any plugin is that it does not block (that is, it does not put itself into the situation where it is waiting for an external event to occur). It is also important that a plugin does not spend too long in each call; if it does, other system events are kept waiting. Input plugins which take too long can cause output devices to stall or stop–start.

This means that both input and output plugins must check to see if more data is waiting or required. Non‐blocking reads must be used, or calls to determine whether there is anything to read before reading.

Windows offers another method to avoid blocking: separate threads or processes can be started to cooperate with the plugin. Note, however, that separate threads may take up CPU time that again may affect the RIP's performance. That said, threads are useful where non‐blocking versions of a call are not available for operations that might block.

Avoiding data underrun

If you are experiencing data underrun in your Windows environment, one of the following hints may help:

• If your plugin does little else but pass data to a driver which in turn does a lot of work, you can avoid the risk of data underrun by using the /plow argument on the RIP's command line. This reduces the RIP priority and can sometimes allow the driver to use more CPU time.
• If you have catch‐up problems at the beginning of each page, consider flushing the file system cache by adding a call either in D_OPEN , or in your D_OUTPUT /D_IDLE state machine a few seconds before you actually begin output.