[zeromq-dev] A simple C++ wrapper of zmq::poll
matt_weinstein at yahoo.com
Tue Aug 31 14:14:48 CEST 2010
On Aug 30, 2010, at 8:34 PM, Radu Braniste wrote:
> Hi Matt,
> Sorry for being late with this answer but I was away for a couple of
No worries, we all have day jobs :-)
> 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 went down several roads, and tossed the "rebuild inside the poll
loop" because it's so cheap to leave, esp. as you're on a single
thread, and it doesn't impose just one way to do things on the user.
Things with pointers and allocation lead to alloc/free bugs,
allocation issues in a static environment, etc., and vector<> is
always around for C++ users. You can always rebuild from a secondary
> 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.
I'm probably going to work on snap ons to allow more generalized data
Of course, the whole thing probably should just be driven by
zmq_msg_t ... :-/
I'm thinking about it :-)
> Radu _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev