-
This makes more sense logically, and lets the Redox object get default constructed with nothing but the optional logger parameters.
-
Explain core commands, pubsub, and reply types.
-
More intuitive if disconnect() blocks like connect(). Most clients will want to use these two methods. For more fine grained control, disconnect() is just a combo of stop() and wait().
-
Configure CMake to generate libredox.so and libredox_static.a, and have all examples use the dynamic library. This is how Redox should be used in practice, and greatly reduces the compilation time of the examples. Also renamed redox.[ch]pp to client.[ch]pp and created one master header redox.hpp for users to include. This header right now just includes client.hpp, command.hpp, and subscriber.hpp.
-
Refactor state management code to use three methods .connect(), .disconnect(), and .wait(). Start conforming to uniform coding style already applied to Command class. Split off subscribe functionality into its own class Subscriber. This is good because it was introducing unnecessary state and complexity into the main client. Now, Redox handles publishing like any other command and the Subscriber receives messages.
-
Now, there is only one callback for command(), and it returns a const reference to the Command object. The user is responsible for error checking using c.ok(), c.status(), and getting the reply with c.reply(). This significantly cleans up the library code and the user code. Greatly refactored the data type specialization code in command.cpp.
-
Consolidated user callbacks into one, improved some logic.
-
Created an atomic_int connect_state that keeps track of not yet connected, connected, disconnected, and errors. Used to implement good error behavior when the server is down and you start() a Redox instance, or when the server goes down in the middle of running commands. Now, nothing should hang, but should return errors (or throw exceptions) when the server goes down. Also added hooks for a user connect/disconnect callback in the constructor, which is helpful for client programs. Added an example with three Redox clients in one thread.
-
Also plan to add in set<string> and unordered_set<string>. Maybe queue<string>. Looking at likely removing char* as an option, if it shows to be about the same speed as string.
-
Thoroughly cleaned up redox.hpp to expose a minimal public API, and commented those well. Generally cleaned up a bunch of stuff. Added wrapper function DEL, which could be useful.
-
Easy few lines for get and set commands that are easy to use. Implemented a condition variable that blocks run() until the event loop is running and Redis is connected. Also added a check to command() that will throw an exception if you try to add a command before calling run().
-
Fixed a couple of bugs found with a test case of 100 parallel asynchronous clients. As of now, there are no known memory leaks, segfaults, or deadlocks in Redox.
-
The event loop (now libev) now runs in a separate detached thread, which is abstracted away from the user, who only calls a nonblocking .start() method. This thread loops continously, alternating telling Redis about asynchronous commands ready to send, and running one iteration of the event loop, where all pending events are taken care of. This greatly simplifies the user code. Additionally, some clever tricker is implemented now to handle memory management well with the templated command types. The difficulty comes from the fact that we pass redis a void pointer only, and must retreive everything from that (so, we can't use shared_ptr for the whole thing). Thus, we use maps of void pointers to their templated data structure pointers, where the memory address of the pointer serves as the key.
-
Basic CMake setup, redisx implementation, and one example program.