[zeromq-dev] Update Re: zmq_reactor on github
Matt Weinstein
mattweinstein at gmail.com
Mon Aug 2 15:23:23 CEST 2010
Folks,
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*
end);
The nice part is the chains of reactors are easy to grok, and these
functions can set up portions of chains differently.
More forthcoming.
Best,
Matt
(*) 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