"Experimental" status of ZMQ_PAIR sockets.

[ClosetGeek-Git]

First, ZeroMQ is awesome, I've been using it for years. However, I'm working on an idea that may need to transition communication from between threads into between processes, and then possibly outward even more into communication over IP. While I can obviously make this work without using ZMQ_PAIR for ipc:// or tcp://, I'm still confused regarding the state of this "experimental" status. To be honest we can only assume that this experimental status only applies to network based sockets because the documentation is not specific on that note. I believe this should be covered in a little more detail, at least to a point where a user isn't left to assume. The specific foot note I'm referring too:

ZMQ_PAIR sockets are designed for inter-thread communication across the zmq_inproc(7) transport and do not implement functionality such as auto-reconnection. ZMQ_PAIR sockets are considered experimental and may have other missing or broken aspects.

http://api.zeromq.org/master:zmq-socket

[edit] I'm posting this here because I believe it's more of a documentation bug than an implementation bug. The specific behavior when using ZMQ_PAIR is understandable, and it's difference between other socket types is understandable as well given the non-trivial difference of communication between endpoints which are in fact related threads. I just feel it's a bit of a hole in the documentation when considering how well ZMQ is otherwise covered inside and out.

[ClosetGeek-Git]

For starters, ZMQ_PAIR sockets are designed for inter-thread communication... is concise and the context clearly relays that ZMQ_PAIR sockets as being intended for inter-thread communication. Using ZMQ_PAIR sockets are designed for in such an specific way, and than simply saying ZMQ_PAIR sockets are considered experimental and may have other missing or broken aspects really leaves a lot to be assumed.

[ClosetGeek-Git]

If I didn't already have a years long grasp of zmq, or if I didn't have a solid background in thread related concepts/design outside of zmq, I'm not sure if I would be able to safely make assumptions on that foot note alone.

[ClosetGeek-Git]

And clearly I'm not sure when it comes to specifics regarding this issue and that would be nice as well. For example, if I was to use a socket monitor to react when a tcp based ZQM_PAIR endpoint disconnected, would this solve the problem or is there deeper issues regarding IPC/IP ZQM_PAIR sockets. I'm not looking for an answer to this, it's purely hypothetical at this point of my design. But it would be nice if the documentation provided a bit more so that I wasn't left guessing or having to explore other avenues to find the answer.

[ClosetGeek-Git]

"Don't do it" is well enough, but it's pointedly lacking.

[ClosetGeek-Git]

To the point that I may start doing some deep evaluation to find and document the specific behavior involved in using ZMQ_PAIR over tcp:// or ipc. I don't see why that is necessary considering the lengths that have gone to both making the API consistent and to document it in both clear and complete form.

[ClosetGeek-Git]

Also, ZeroMQ doesn't attempt to provide a 100% reliable or 100% fault tolerant solution for networking/IO, at least not purely as an implementation detail. ZMQ's current ecosystem instead attempts to fully document these aspects to allow development of higher-level protocols/patterns for handling these details. I believe documenting potential issues related to ZMQ_PAIR over icp/tcp would better fit this aspect of ZMQ's culture, and may be the start of solving the problem without necessarily making ZMQ_PAIR over true sockets 100% reliable at their core. It may simply be possible within the pattern detail once fully understood. In fact experience makes me think it very likely is solvable without core changes to the API.