[zeromq-dev] Using shared objects as clients

Charles Remes lists at chuckremes.com
Tue Nov 27 22:33:49 CET 2012

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. :)


On Nov 27, 2012, at 1:32 PM, Brad Taylor <cbradtaylor at gmail.com> 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list