> This whole thing works, but NOT most of the time. Sometimes the new > thread writes the reply on inproc://r but the main thread never wakes up > from the poll. Or, the main thread writes the message on inproc://r but > the new thread never receives it. The only common factor between the two > errors is the use of an inproc socket between the two threads. I have > taken care to create each socket within its proper thread. > > The fact that it DOES work sometimes is the most tantalizing. I thought > I would run this design by the list to check for any more-than-usual > stupidity on my part, before I dive into the debugging process. Could > this be related to the use of REQ/REP sockets and their strict ordering > semantics?
I replaced the inproc sockets with plain tcp sockets. I still see the same problem; it works sometimes but, even it fails as described above, even more often than with inproc sockets. So, it is not inproc sockets at the root of the problem. Could it be the REQ/REP sockets? Say I have a REQ or REP socket. Can I do a poll() on it before anything is sent or received on the socket? If I poll() such an unused socket for, say, 5 seconds, will it block for at most those 5 seconds? If a message arrives within those 5 seconds, will poll() return right away? What would happen if I tried to poll() such a socket before the connection has been internally established by 0MQ? I know this all sounds pretty bread-and-butter-y, but I am just trying to make sure I've got the basics covered. Thanks. -- Gonzalo Diethelm _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
