3 ms·
The problem with ZeroMQ is that it is highly opinionated about threading and concurrency in a way that doesn't necessarily mesh well with other components of yo
by cmrdporcupine 3y ago
The problem with ZeroMQ is that it is highly opinionated about threading and concurrency in a way that doesn't necessarily mesh well with other components of your application stack that have their own opinions
http://wiki.zeromq.org/blog:multithreading-magic http://wiki.zeromq.org/blog:multithreading-magic
There's nothing wrong with the opinions presented there -- but it really wants to own your whole threading / serving stack, and isn't really compatible with e.g. a Rust async tokio binary where threads can "move around" etc.
- wallstprog 3y agoWell, 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). However, it's not that hard to work around their non-thread-safe nature with a single dispatch thread (e.g., see <https://github.com/nyfix/OZ/blob/master/src/transport.c#L457 https://github.com/nyfix/OZ/blob/master/src/transport.c#L457>), and that approach has other potential benefits. 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).