¿Cuál es el razonamiento detrás del contexto zeroMQ?

Question

Mientras hurgando zeroMQ (A very useful socket replacement for those who don't know), me encontré con esta pregunta en la lista de correo:

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

¿Hay una desventaja de usar múltiples contextos? Tengo un contenedor de clases que me gustaría mantener lo más simple posible. Puedo modificarlo para permitir conexiones múltiples, sockets, etc. en un contexto único o dejarlo como está y hacer que los clientes del contenedor lo instancian varias veces.

Dos desventajas como yo lo veo.

1. consumir recursos a ningún buen efecto (huella de memoria adicional, otro hilo de E/S, etc.)
2. conectores creados en diferentes contextos no puede se comunican entre sí utilizando el transporte del 'inproc'. El nombre 'inproc' es un poco inapropiado; realmente significa "intracontext".

cr

Mirando hacia atrás en la mina y varios otros código fuente, al final me di cuenta de que el contexto configuración código:

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); 

Podría efectivamente se sustituye por:

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] 

Y eso es lo que hice con las macros. Hace las cosas más fáciles para tener 1 variable menos para rastrear (entre otros 100). Aunque está lejos de ser "ideal", ya que requiere que las macros estén dentro del mismo "alcance de función", aunque esto podría resolverse fácilmente.

Si bien mi ejemplo es C, esto es un tanto independiente del idioma.

---

De ahí la pregunta, ¿cuál es el punto/beneficio de la creación de este tipo de contextos?

¿Cuándo es realmente un inconveniente permitir tal característica? Porque puedo prever fácilmente muchos (que solo copiar/pegar/editar código), no tener en cuenta la sobrecarga adicional, y crear "muchos contextos" cuando no es necesario [visto esto muchas veces para otra estructura similar, aunque su existencia tiene su propia justificación]

Una de las razones por las que digo esto, es el hecho de que estoy considerando usar zeroMQ, en un módulo de programación de juegos para principiantes. En gran medida, en parte debido a su simplicidad, y al hecho de que los enchufes tienden a freír las células cerebrales para los nuevos tipos.

---

aleatoria, en realidad justifica la razón de ser del sistema contexto V8 de Google (pregunta similar; sistema diferente): What is the design rationale behind HandleScope?

Answer 1

Es una buena pregunta. Si no necesitas guardar el contexto global, ¿por qué incluso pedirle a la aplicación que lo cree? libzmq podría configurar trivialmente su estado cuando sea necesario la primera vez.

Sin embargo, el problema con la API anterior de 0MQ no es que te obligue a usar contextos, ya que se trata de una clase primaria natural para sockets. El problema es que, habiéndose dedicado al esfuerzo de crear y seguir contextos, casi no obtiene ningún valor para su trabajo. Parece todo costo y sin beneficio.

Si mira las API más recientes, p. CZMQ y 0MQ/3.1 verás que los contextos son mucho más útiles. En CZMQ, limpiamos y destruimos todos los enchufes al destruir un contexto. Eso es realmente útil. En 0MQ/3.1 agregamos alguna configuración de contexto, como el número de subprocesos de E/S, etc. Además, la API es más consistente (zmq_ctx_new, zmq_ctx_set/get, zmq_ctx_destroy) con un modelo de clase (y se parece más a CZMQ también).