[zeromq-dev] A simple C++ wrapper of zmq::poll

[Matt Weinstein]

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  
> days.

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  
structure.

>
>
>
>
> ___________________________________-
> 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  
structures.

Of course, the whole thing probably should just be driven by  
zmq_msg_t ... :-/

I'm thinking about it :-)

>
> Best,
> Radu _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Best,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100831/ca05206d/attachment.htm>