17

While poking around zeroMQ (A very useful socket replacement for those who don't know), I came across this question in the mailing list:

Using multiple contexts : Is there a downside to using multiple contexts?

Is there a downside to using multiple contexts? I have a class wrapper I’d like to keep as simple as possible. I can either modify it to allow multiple connects, sockets etc under a single context or leave it as is and have clients of the wrapper instantiate it multiple times.

Two downsides as I see it.

  1. Tying up resources to no good effect (extra memory footprint, another I/O thread, etc)
  2. Sockets created in different contexts cannot communicate with each other using the 'inproc' transport. The name 'inproc' is a bit of a misnomer; it really means "intracontext."

cr

Looking back at mine and various other source code, I eventually realized that the context set-up code:

void *context = zmq_init (1); //creates the context 

void *responder = zmq_socket (context, ZMQ_REP); //creates the socket

zmq_bind (responder, "tcp://*:5555"); //and binds it

... //Do whatever you want with the socket ...

zmq_close (responder); //destructors
zmq_term (context);

Could effectively be replaced by:

void *context = zmq_init(1); //saving the context is optional

responder = zmq_socket(type); //creates the socket
//additional [context] can be provided if desired (multi-context?)

zmq_bind (responder, "tcp://*:5555"); //and binds it

... //Do whatever you want with the socket ...

zmqx_dest(); //destroys the global context, else provide alternative [context]

And that's what I did with macros. It makes things easier to have 1 variable less to track (among 100 others). Though its far from "ideal" as it requires the macros to be within the same "function scope", though this could be easily solved.

While my example is C, this is somewhat language-agnostic.

Hence the question, what is the point/benefit of creating such contexts?

When its actually a downside to allow such a feature? Cause I can easily foresee many (who just copy/paste/edit code), not take into account the extra overhead, and create "lots of contexts" when its not needed [seen this many times for other similar structure, though their existence has its own justification]

One of the reasons I am saying this, is the fact I am considering using zeroMQ, in a beginners game programming module. Quite largely in part due to its simplicity, and the fact that sockets tend to fry brain cells for the new guys.

Random, I actually justified the rationale of google's V8 context system (similar question; different system): What is the design rationale behind HandleScope?

Community
  • 1
  • 1
PicoCreator
  • 9,886
  • 7
  • 43
  • 64

1 Answers1

19

It's a good question. If you don't need to save the global context, why even ask the app to create it? libzmq could trivially set-up its state when needed the first time.

However the problem with 0MQ's older API isn't that it forces you to use contexts, since these are a natural parent class for sockets. The problem is that having gone to the effort of creating and tracking contexts you get almost no value for your work. It seems all cost and no benefit.

If you look at the more recent APIs, e.g. CZMQ and 0MQ/3.1 you'll see that contexts are much more useful. In CZMQ, we cleanly shut-down and destroy all sockets when destroying a context. That is really useful. In 0MQ/3.1 we added some context configuration, such as number of I/O threads, etc. Also the API is more consistent (zmq_ctx_new, zmq_ctx_set/get, zmq_ctx_destroy) with a class model (and looks more like CZMQ too).

Pieter Hintjens
  • 6,599
  • 1
  • 24
  • 29