Hi all,
I've volunteered to take on some of this inproc task. I haven't been
looking at linked issues because, like Garrett, I'm hoping that correcting
any thread-safety issues will take care of many of them. But if anyone
wants to link inproc bugs in this thread, feel free so that we have a check
list to go through at the end of this.
My team is working with nanomsg and would like to use inproc, but either of
TCP or IPC are viable alternatives (possibly with a few additional bugs
fixed) for us if inproc takes me too long to sort out. So, with that being
said, I don't have a timeline for this getting taken care of, and am not
sure if I could even give a rough estimation. If it's only a matter of a
few days, that's great for us all. Otherwise I expect it to take a bit
longer because I will have to work on it on my own time, which is
inconsistently used for programming tasks. If it's taking too long for
your liking, feel free to make an attempt yourselves :).
- Sam
On Tue, Jun 2, 2015 at 10:37 PM, Bent Cardan <bent@xxxxxxxxxxxxxxxxxxxx>
wrote:
and how about a link to this crossroads code?
Best regards,
Bent
On Tue, Jun 2, 2015 at 6:59 PM, Timothee Besset <ttimo@xxxxxxxxx> wrote:
So who is this person working on inproc and what does he need? Can you
link the relevant github issues?
Best,
TTimo
On Mon, Jun 1, 2015 at 4:24 PM, Garrett D'Amore <garrett@xxxxxxxxxx>
wrote:
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
