Multithreading with the Hipe API
How should you use the Hipe API if your application contains multiple threads?
The safest possible approach is to limit interactions with the Hipe API to a single thread, regardless of how many threads you have. Nonetheless a degree of thread safety exists within Hipe.
As of version 1.03, sending a completed instruction to the Hipe display server is an atomic, thread-safe operation. This means that if multiple threads send instructions to the hiped server at the same time, the Hipe API will ensure that the instructions are serialised.
Receiving (and waiting on) instructions is not thread-safe. Only one thread should receive instructions at a time. Otherwise incoming instructions may be decoded in a garbled way. Hipe also has no Earthly way of knowing which instructions are wanted by which thread&emdash;the display server sends all instructions to the process via a single linear queue.
Example
One sensible compromise is to use one thread for handling the bulk of graphical interactions with the user, while using another thread to display information that does not require user interaction; sending only instructions that do not generate (or require) a reply from the display server. As long as the second thread doesn't compete with the main thread for being the first to append an element to a particular location, for instance, the desired result is guaranteed each time the program runs.