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 :-)

Radu _______________________________________________
zeromq-dev mailing list