(v13) Writing plugins as state machines

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

Plugins can be written as state machines to avoid the possibility of blocking. These state machines maintain a record of how far they have proceeded through a particular task so that control can be passed back and forth between the plugin and the RIP without losing track of what has been achieved so far.

The code example below illustrates how such a state machine might be written.

    int stateId = state1;
    ...
        switch (stateId) { case state1:
                if (todayIsMonday) { doMondaySomething(); stateId = state2;
            }
        break; case state2:
                if (todayIsThursday) { doThursdaySomething(); stateId = state1;
            }
            break;
    }
    return;

This state‐machine plugin interface is started off by setting stateId to state1 . It waits for Monday to arrive. When it does, it performs a task. After this it waits for Thursday to arrive, and then performs another task. After completing its Thursday task, it goes back to waiting for Monday. During these ‘waiting' periods, control will immediately be passed back to the RIP upon a plugin call.

As well as being guaranteed not to block, the state machine is a simple means of ensuring that preconditions are met before a certain task is undertaken. If we start the state machine above off with stateId as state1 we know that doMondaySomething must have been called before doThursdaySomething is called.