[zeromq-dev] zmq_reactor API question

[Matt Weinstein]

ØMQ devices are ordinarily used to connect two sockets to e.g. solve  
the back-to-back bind problem, or to perform other simple transfer  
operations.

You can construct more complex devices yourself by building the poll  
vectors and doing the housekeeping.  These devices can be used for  
things like timeout/recovery, server pooling, failover, load  
balancing, etc.

zmq_reactor is a helper library that implements an event driven  
(callback/reactor) paradigm on top of zmq_poll(), offering support for  
simple polling strategies (priority order, downstream polling, etc.)

I consider it a first generation model, but it's pretty useful as it  
stands.

Best,
Matt

On Aug 11, 2010, at 4:28 PM, gonzalo diethelm wrote:

> Matt, allow me to reply with a request: could you provide a little  
> more information on what the use case for zmq_reactor is? I reviewed  
> the samples on the git repo but I am not sure exactly what your  
> goals are with the code (at a very high level). Forgive my being  
> obtuse…
>
> Thanks and best regards.
>
> Gonzalo Diethelm
>
> From: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org 
> ] On Behalf Of Matt Weinstein
> Sent: Wednesday, 11 August, 2010 14:27
> To: zeromq-dev at lists.zeromq.org
> Subject: [zeromq-dev] zmq_reactor API question
>
> Is the linked list form of zmq_reactor_t too complex?
>
> The current linked-list form of the zmq_reactor interface was  
> conceived of to allow easy manipulation of the linkages on the fly,  
> primarily through policy callbacks.  However, that rationale no  
> longer applies because policies have been replaced by the IOP format  
> we have today.
>
> I am leaning toward re-writing the interface to zmq_reactor to  
> mirror zmq_poll:
>
>           int zmq_reactor_poll (zmq_reactoritem_t *items, int  
> nitems, long timeout);
>
> We are probably early enough in the usage and evolution of the  
> library to change this easily.  This will eliminate a lot of  
> structural complexity without a lot of downside.
>
> Finally, we could always allow "poll block chaining" in future  
> versions if this were a necessary feature.
>
> Please let me know what you think?
>
> I'm leaning in favor of this change, so please object strongly if  
> it's important.
>
> If I don't hear serious objections I will start branching this PDQ.
>
> RSVP,
>
> Thank you,
>
> Best,
>
> Matt
>
>
>
> Declaración de confidencialidad: Este Mensaje esta destinado para el  
> uso de la o las personas o entidades a quien ha sido dirigido y  
> puede contener información reservada y confidencial que no puede ser  
> divulgada, difundida, ni aprovechada en forma alguna. El uso no  
> autorizado de la información contenida en este correo podrá ser  
> sancionado de conformidad con la ley chilena. Si usted ha recibido  
> este correo electrónico por error, le pedimos eliminarlo junto con  
> los archivos adjuntos y avisar inmediatamente al remitente,  
> respondiendo este mensaje.
>
> Disclosure: This Message is to be used by the individual,  
> individuals or entities that it is addressed to and may include  
> private and confidential information that may not be disclosed, made  
> public nor used in any way at all. Unauthorized use of the  
> information in this electronic mail message may be subject to the  
> penalties set forth by Chilean law. If you have received this  
> electronic mail message in error, we ask you to destroy the message  
> and its attached file(s) and to immediately notify the sender by  
> answering this message._______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100811/7fe838d7/attachment.htm>