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

[Radu Braniste]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100830/67d3138e/attachment.htm>