Hi Matt, Sorry for being late with this answer but I was away for a couple of days. A couple of comments:
___________________________________________ > 1: 100% C++ with different ways of expressing the event handlers > (not a choice for people looking for plain C) > I wrote mine in C figuring it might be compatible with other language ports, and operates at the same level as the zeromq library. It's actually relatively easy to wrap this into a class, but the re- use is in the methods, rather than in attached objects right now. That can be handled with some forwarding. _________________________________ This is a plus for your library. Mine can be wrapped up in plain C but it looses some genericity (one have to actually specialize the templates for every case of interest). ___________________________________________________- > 3: Allows full access at every step of polling - user can > manipulate directly & dynamically state and/or event handlers (add/ > remove/change) > I found this doesn't happen often enough in a real-world scenario to require it from poll to poll, and the data structure was too balky. I simplified it by allowing any reactor to cause the poll to return with a status code of its choosing, and the wrapper around it can then call with an updated poll vector (literally I'm using stl::vector). ____________________________________________________ One of the perceived benefits of a reactor's interface is the dynamic add/remove of event handlers ( http://www.cs.wustl.edu/~schmidt/PDF/reactor-siemens.pdf). I choose to make the user responsible for building the poll loop because the resulting code might be cleaner. A couple of days ago I supplemented my reactor interface with a "run" method that practically creates the poll loop but allows customization through a "template": poll() is sandwiched between two user-defined functions thus allowing full control of polling process ___________________________________- I tried for a simple "microcode" after having built complex policies. Probably the next approach should be a policy that operates on some additional data in the vector, and let it make the switching decisions. The current "policy" would then just snap on, as e.g. zmq_reactor_poll_policy(.... microcode_policy). ________________________________________ An interesting approach... the microcode might be found less labour intensive by many users. Best, Radu
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
