Building a Multithreaded Stack and API
The client stack weâve used so far isnât smart enough to handle this protocol properly. As soon as we start doing heartbeats, we need a client stack that can run in a background thread. In the Freelance pattern at the end of Chapter 4, we used a multithreaded API but didnât explain it in detail. It turns out that multithreaded APIs are quite useful when you start to make more complex ÃMQ protocols, like CHP.
If you make a nontrivial protocol and you expect applications to implement it properly, most developers will get it wrong most of the time. Youâre going to be left with a lot of unhappy people complaining that your protocol is too complex, too fragile, and too hard to use. Whereas if you give them a simple API to call, you have some chance of them buying in.
Our multithreaded API consists of a frontend object and a background agent, connected by two PAIR sockets (Figure 5-8). Connecting two PAIR sockets like this is so useful that your high-level binding should probably do what CZMQ does, which is package a âcreate new thread with a pipe that I can use to send messages to itâ method.
Figure 5-8. Multithreaded API
The multithreaded APIs that we see in this book all take the same form:
The constructor for the object (
clone_new()) creates a context and starts a background thread connected with a pipe. It holds onto one end of the ...
Get ZeroMQ now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
