Join GitHub today
Reactor polling pattern for ZeroMQ
Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
WELCOME ======= zmq_reactor is intended to be a "reactor" style interface which will support building complex communication patterns with ØMQ. BACKGROUND ========== After working with ØMQ a bit, there was a recognition that the logical place to extend ØMQ to add certain types of "common" functionality, such as heartbeats, client request timeouts, etc. appeared to be in the "devices" which perform multiplexing and forwarding functionality between sockets. However, adding functionality required copying the device code, adding another socket here or there, or perhaps add a queue or thread or two to handle things. (Martin S. did not approve of this :-) ) Subsequently attempts were made to create e.g. a multi-argument device(...) or equivalent, but they didn't capture the efficiency, functionality and elegance inherent in ØMQ. After some meditation, there was a recognition that the two essential elements of the ØMQ model that needed to be captured were the efficiencies inherent in ypipes (the lockless pipes in ØMQ), and the centralized control and efficiency inherent in the single-threaded model of the device subsystem. After a bit more meditation, and some typing(*) - zmq_reactor was born. CAVEATS ======= These modules are Still a work in progress, but I wanted to get the concepts out there so the community could consider it, and improve upon it. IMPLEMENTATION NOTES ==================== Rationale for using doubly-linked lists: - STL lists et al would be hard to manipulate from a handler - You can derive from a zmq_reactor_t, and manipulate your class from a policy or a handler KUDOS ===== Many thanks to [X+1] for allowing me to open source this work. (*) About 90 minutes or so all told :-)