Hmmm, the main "problem" would be that debugging will be awfully hard.
Other than that, there is no (reasonable) limitation on the number of contexts you create. The whole purpose of a zmq_context is to solve the library problem that you describe, so if it doesn't work then there is a fundamental problem with zeromq itself. :) cr On Nov 27, 2012, at 1:32 PM, Brad Taylor <[email protected]> wrote: > I am working on a semi large application that will be deployed in a blade > server environment. Various parts of the app will run on various blades. On > any given blade, a piece of the app may need to invoke "client" services. We > are planning on utilize zmq for our client and server messaging functions. > > Due to the architecture of the app, various components are implemented as > shared objects, aka libraries. These libraries provide component specific > functionality, and are not "aware" of the overall context in which they are > invoked. > > Thus in the same thread, or in multiple threads, we want to be able to invoke > zmq client code. Since zmq requires a context, I am planning on each client > service to get its own zmq context. I am unsure if this will cause any > potential conflicts within zmq. > > Another way of saying this, is my linux process MAY have multiple zmq > contexts within the same thread, or in multiple threads (pthreads). These > will only be "client" type of requests. We will always "bracket" the > services, aka closes for open, destroys for news, etc. > > Does anyone see any "problems" with this approach? > > Thank you > > Brad Taylor > _______________________________________________ > 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
