(v13) Writing plugins using threads

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

All supported operating systems now support pre-emptive multi‐tasking. This means an alternative strategy for writing plugins is now accessible on all platforms, namely using threads to implement plugins.

The plugin itself, which runs synchronously with the RIP, is simply responsible for queueing requests and data to a second thread. This thread consumes the data in its own time and returns requests to the RIP‐side of the plugin to update the RIP with its progress (for example in an output plugin, by updating d_linescopied ).

This provides for a simpler structure in the second thread: it need only loop consuming data. However, it does require proper co‐ordination between the threads to ensure that the queue of requests is treated as a critical section, protected by semaphores.

Note: The second thread should not update RIP data structures directly, as the RIP does not expect changes to happen randomly, but only on return from a call to a plugin.

The preferred way of using threads is via the threads API. For more information see the Harlequin API Reference Manual .

The thread API gives access to a subset of pthreads. When you use the thread API extracted via the RDR call you are using the same implementation that is in the RIP. The plugin can get hold of the API pointer and then it can create threads, new condition variables and so on. That is, it can create any‐ thing that is in the subset of pthreads that is exposed. This is the preferred way of creating, running and synchronizing threads with the plugin and RIP.

The events and timelines available are defined in the file plugevtls.h . These are the events and time‐ lines used for communications between the plugin and the RIP.

You can use the events and timelines to communicate with the RIP asynchronously. That is, from another thread that the plugin is running out of the scope of a selector call.

Note: You can only update the device definition structure, such as d_linecoped and d_linesprinted and so on, when the RIP is making a selector call.

So, if the plugin is running in a separate thread and that finishes you cannot directly change d_linecoped and d_linesprinted . However, you can issue a timeline progress update. There are two timelines defined for communication between the plugin and the RIP. For more information see Currently available timelines .