Just so everyone knows it: the inproc transport in libnanomsg is pretty clearly
fraught with problems. At the most basic level, it suffers from a lack of
synchronization control (locks) protecting some of the state shared between the
two endpoints of a connection (in particular the state machine content is not
carefully protected, although both ends participate in informing each other of
new content.)
Since the only conceivably useful case for inproc I can think of involves
different threads on the two different ends of a connection, this makes it
effectively useless until those bugs are fixed.
At least one person has volunteered to work on this part of the code. I’ve
tried to fix a few of the issues, but the heart of the issue is going to
require some careful design work with the locking to ensure it works, and does
not create new deadlock scenarios. As I don’t use inproc myself, I can’t
really say that this has any sense of priority on my part — I’d like to fix it,
but my own itches tend to get scratched first, and I’ve plenty enough of those.
In the meantime, I’d appreciate it if folks can try to avoid using inproc where
possible, and in particular try to refrain from filing new bugs against inproc.
With the lack of thread-safety in it, I suspect *many* of the strange
behaviors folks have reported will go away when inproc is properly fixed.
Note that none of this applies to mangos. The inproc code in mangos, as well
as the rest of mangos, has been carefully designed to be completely thread
safe, and should not have any issues there. (I can’t imagine what you’d use
inproc for in a Go program… but its there. Inproc in mangos is not compatible
with libnanomsg inproc, in the sense that you can’t pass messages between them.)
(One idea I’ve been toying with is to have inproc convert to using a pipe()
based pair of file descriptors. This would let us use the kernel and avoid the
synchronization problems altogether, although it would make inproc noticeably
slower.)
- Garrett
