[zeromq-dev] Update Re: zmq_reactor on github

Matt Weinstein mattweinstein at gmail.com
Mon Aug 2 15:23:23 CEST 2010


I just committed an moved from the "policy" flavor to a more microcode  
flavor of the architecture.

This is an intermediate version, with certain non-functionality  
(options DO NOT WORK) (*).  The zmq_reactor_policy_t hooks are  
superannuated and no longer publicly visible.

However, the interface for polling has been simplified to one  
function, namely zmq_reactor_poll().


A few folks have asked how they can get their heads around this.

One way might be to look at this as an IO unit on a mainframe.

The poll "processor" assembles packets from various connections and  
executes "microcode" to munch them and send them on their way.

The goal is to support a lot of common use cases, such:

	- strictly ordered polling and handling of multiple sockets
	- priority-based polling of multiple sockets
	- chained polling of subordinate sockets
	- polling while enabling disabling sockets (for failover, if a server  
is not available, etc.)
	- "always" callbacks (for special processing)

and potentially anything else you can think of, all on a single  
processor (thread).

By providing reasonable functionality at this level, zmq_reactor  
supports both low- and high- level language interfaces, potentially  
eliminating the need for re-implementation of e.g. packet switching in  
every language.

FYI, the algorithms in zmq_reactor_options.* files are intended to  
apply specific policies/patterns to a chain of reactors, e.g.:

	zmq_reactor_use_priority_polling(zmq_reactor_t* begin, zmq_reactor_t*  

The nice part is the chains of reactors are easy to grok, and these  
functions can set up portions of chains differently.

More forthcoming.



(*) and the old code has been stuffed into the zmq_reactor.cpp file,  
very ungraciously.  I've apologized profusely. :-)

More information about the zeromq-dev mailing list