Threading Redis-Verbindung in C++

Question

Ich frage mich, wie Redis NOSQL Aufrufe in die C++ Std Threading-Bibliothek Code aus dem C++ Concurrency in Action Book implementieren.

ich die Github Repo von
https://github.com/subjam/concurrency-in-action

Quelldatei bin mit https://github.com/subjam/concurrency-in-action/blob/master/ch7/stack.cpp

ich mich gefragt, ob ich meine Redis NoSQL-Verbindungscode in der push() Funktion platziert ist weise.

Ich verwende auch Redox, die ein C++ - Wrapper ist, der die Hiredis C-Bibliothek enthält.

https://github.com/hmartiro/redox

Ich bin mit dem Teilnehmer NoSQL-Muster, die in der Threading push() Funktion enthalten sein würde. Dies würde die Verbindung und die Abfrage jedes Mal ausführen, wenn ein Push erfolgt, aber kein Semaphor/Mutex würde benötigt werden (nehme ich an). In Zeile 145 von push() in stack.cpp, kann ich die push Funktion wie neu schreiben?

void push(stack<int>* s) 
{ 
    Redox rdx; Subscriber sub; 
    if(!rdx.connect() || !sub.connect()) return; 

    sub.subscribe("hello", [](const string& topic, const string& msg) { 
      …parse msg fields into data structure … 
    s->push(data); 

    }); 
} 

Oder sollte ich die folgende Verbindungscode einmal machen, bevor die push() Funktion ausführt?

Redox rdx; Subscriber sub; 
if(!rdx.connect() || !sub.connect()) return ; 

Würde ein Einfädeln Konflikt da sein, wenn ich den Redis Verbindungscode halte außerhalb der push()
Oder gibt es einen optimalere Weg, dies zu Codierung innerhalb stack.cpp? Danke

Answer 1

Ihre push Funktion würde nicht funktionieren, wie Sie wahrscheinlich erwartet haben. Das Abonnement wird sofort nach dem Anruf sub.subscribe():

void push(stack<int>* s) { 
    // No need for Redox object here. 
    Subscriber sub; 
    if (!sub.connect()) return; 

    sub.subscribe("hello", [](const std::string& topic, const std::string& msg) { 
     // parse msg fields into data structure 
     s->push(data); 
    }); 
    // sub object will be destroyed here, 
    // subscription to the "hello" topic will be interrupted. 
    // Additionally, some resources might leak, 
    // since sub.disconnect() was not called. 
} 

zerstört werden