On Sep 24, 2010, at 10:35 PM, Praveen Baratam wrote: > Dear Chuck, > > Thanks for writing back. > > I did take a look into the zmq_reactor. the examples were not so clear and > there is no documentation of the library and its api. i guess i should infer > everything from the code. > > I was wondering whether this reactor will yield any performance benefit apart > from provisioning a API. When it comes to normal sockets the benefit of ASIO > (Reactor/Proactor pattern) is obvious because the OS kernel paves the path > for it. Unless such an optimization exists inside zmq kernel and the added > overhead of container (vector, unordered_map used inside reactor) lookup, > modification etc is lesser than thread-per-socket approach, there is no point > in using it. > > I guess the developers of ZMQ will be able to throw more light on this issue. > > Have you tried using zmq_reactor anytime?
Praveen, I'm a Ruby guy so I wrote my own and put it up on github. http://github.com/chuckremes/zmqmachine I use the reactor pattern all of the time but I avoid C and C++ because it takes too many lines of code to do even simple things. I get more bang for the buck from my choice of the Ruby language albeit at the price of lower execution performance. You may want to search the archives for zmq_poll and all of the discussions on its redesign. The 2.1.x branch has the code for the redesign whereas the currently public version (2.0.9) has the original API. I think 2.1 will have backward compatibility for the current poll API, but it will also expose a few more details for people interested in doing some high performance tricks. Also, zmq_poll uses the best poll API supported by the kernel on your platform (poll, epoll, kqueue) so it's pretty well optimized. Again, look at the code. It's pretty accessible. cr _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
