It may be safe for inproc, but I never write code using this assumption. Any change to the transport type breaks the application because the others are all asynchronous.
This is a long-time and well-known flaw in the library. The inproc transport is different and it causes problems when part of the marketing message in zeromq says that you can start with in-process communication and effortlessly scale out just by changing a single line of code. I'm not blaming anyone; I realize it's a hard problem to solve. cr On Oct 18, 2012, at 11:03 PM, Pieter Hintjens wrote: > On Fri, Oct 19, 2012 at 7:45 AM, Chuck Remes <[email protected]> wrote: > >> No, it is not guaranteed that socket3 will be ready for a connection. All >> binds (and connects) happen asynchronously in the I/O thread. Depending on >> your machine performance, it could be ready in 10ms, 100ms or more. > > Hmm, on inproc the connects and binds happen synchronously, so this is safe. > > Here's the pattern that CZMQ uses for this (which has been heavily > tested and works): > > - create one socket > - bind to inproc address > - create child thread and pass context > - child thread creates second socket > - child thread connects to inproc address > > This works very well with PAIR sockets. > > There is an explanation of the inproc:// behaviour on the zmq_inproc man page. > > -Pieter > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
