Briefly mentioned elsewhere in the comments, but C++11 had a similar issue around the transition from a copy-on-write (COW) to a small-string-optimization (SSO) implementation for std::string. If any type is more ubiquitous than std::string, I don't know what it could be, but the transition was reasonably painless, at least in my shop.
If you're using dynamic linking, the following two tools will come in very handy:
- pldd (https://man7.org/linux/man-pages/man1/pldd.1.html) shows the actual dynamic libs linked into a running process. (Contrast this with ldd, which shows what the dynamic libs would be based on the current shell environment).
We've open-sourced the tools we use to run valgrind (and ASAN) on large mixed C++/Java code bases. The JVM in particular triggers a slew of errors which can make filtering valgrind output impractical, but the scripts we developed can handle that. FWIW, we use these tools every day on the code that goes into NYFIX Marketplace (https://www.broadridge.com/financial-services/capital-market...).
I thought it was a brilliant design, but it was dog-slow on hardware at the time. I keep hoping someone would revive the design for current silicon, would be a good impedance match for modern languages, and OS's.
Well, the original non-thread-safe sockets (e.g., ZMQ_SUB, etc.) were that way because they support multi-part messages. And yes, the fact that they are not thread-safe is a bit of a stumbling-block for ZeroMQ newbies (including me, back in the day).
In any case, newer socket types (e.g., ZMQ_CLIENT) have since been defined that are thread-safe, but necessarily don't support multi-part messages. (They tend to be different in other ways as well -- e.g., ZMQ_RADIO/ZMQ_DISH are "sort of" replacements for the original ZMQ_PUB/ZMQ_SUB sockets, but have other constraints as well).
Unlikely, but they seem to be different things altogether. BlazingMQ appears to be a traditional message queue (think ActiveMQ), with message peristence. ZeroMQ is more of a network middleware (think Tibco Rendezvous), and does not include persistence.
BlazingMQ also appears to be more of a "platform" or "service" that an app can use (sort of like Oracle, say) -- ZeroMQ includes libraries that one can use to build an app, service or platform, but none is provided "out of the box".
Which makes it harder to get started with ZeroMQ, since by definition every ZeroMQ app is essentially built "from scratch".
If you're interested in ZeroMQ, you may want to check out OZ (https://github.com/nyfix/OZ), which is a Rendezvous-like platform that uses the OpenMAMA API (https://github.com/finos/OpenMAMA) and ZeroMQ (https://github.com/zeromq/libzmq) transport to provide a full-featured network middleware implementation. OZ has been used in our shop since 2020 handling approx 50MM high-value messages per day on our global FIX network.