Qual è la logica dietro il contesto zeroMQ?

Question

Mentre rovistando zeroMQ (A very useful socket replacement for those who don't know), mi sono imbattuto in questa domanda nella mailing list:

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

C'è un aspetto negativo di utilizzare molteplici contesti? Ho un wrapper di classe che vorrei mantenere il più semplice possibile. Posso modificarlo per consentire più connessioni, socket ecc. In un singolo contesto o lasciarlo così com'è e avere client del wrapper che lo istanzano più volte.

Due lati negativi come la vedo io.

1. impegnare risorse a nulla di buono effetto (occupazione di memoria in più, un altro thread di I/O, ecc)
2. socket creati in diversi contesti non può comunicano tra loro usando i mezzi della 'inproc'. Il nome "inproc" è un po 'improprio; significa davvero "intracontext".

cr

Guardando indietro al mio e vari altri il codice sorgente, alla fine ho capito che il codice di set-up contesto:

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

potrebbe efficacemente sostituito dal seguente:

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] 

E questo è quello che ho fatto con i macro. Rende le cose più facili avere 1 variabile in meno da tracciare (tra 100 altri). Anche se è lontano dall'essere "ideale" in quanto richiede che i macro si trovino all'interno dello stesso "ambito di funzione", benché ciò possa essere facilmente risolto.

Mentre il mio esempio è C, questo è in qualche modo indipendente dal linguaggio.

---

Di qui la domanda, qual è il punto/vantaggio di creare tali contesti?

Quando è in realtà uno svantaggio per consentire tale funzionalità? Perché posso facilmente prevedere molti (che semplicemente copia/incolla/modifica il codice), non prendere in considerazione il sovraccarico extra e creare "molti contesti" quando non è necessario [visto questo molte volte per altre strutture simili, sebbene la loro esistenza abbia la propria giustificazione]

Uno dei motivi per cui sto dicendo questo è il fatto che sto considerando l'utilizzo di zeroMQ, in un modulo di programmazione di giochi per principianti. Abbastanza in gran parte a causa della sua semplicità, e il fatto che le prese tendono a friggere le cellule cerebrali per i nuovi ragazzi.

---

a caso, in realtà ho giustificato (domanda simile; sistema diverso) la logica del sistema di contesto V8 di Google: What is the design rationale behind HandleScope?

Answer 1

E 'una buona domanda. Se non è necessario salvare il contesto globale, perché persino chiedere all'app di crearlo? libzmq potrebbe banalmente impostare il suo stato quando necessario la prima volta.

Tuttavia, il problema con l'API precedente di 0MQ non è che obbliga a utilizzare i contesti, poiché si tratta di una classe genitore naturale per i socket. Il problema è che, quando si è passati allo sforzo di creare e tracciare contesti, non si ottiene quasi alcun valore per il proprio lavoro. Sembra tutto a costo e nessun beneficio.

Se si guardano le API più recenti, ad es. CZMQ e 0MQ/3.1 vedrai che i contesti sono molto più utili. In CZMQ, chiudiamo e distruggiamo in modo pulito tutti i socket quando si distrugge un contesto. Questo è veramente utile. In 0MQ/3.1 abbiamo aggiunto alcune configurazioni di contesto, come il numero di thread I/O, ecc. Anche l'API è più coerente (zmq_ctx_new, zmq_ctx_set/get, zmq_ctx_destroy) con un modello di classe (e sembra anche CZMQ).