[zeromq-dev] Minor update to zmq_reactor
gonzalo diethelm
gdiethelm at dcv.cl
Wed Aug 25 15:29:54 CEST 2010
Matt, I have not seen your code, so my comments may not apply. I
understand there already is code in 0MQ to generate UUIDs; if you are
reusing / improving this code, I think it would be a good idea to
encapsulate it in a single place.
In addition, I have always thought UUID generation should be one of the
utility functions from 0MQ (same as zmq_stopwatch_start,
zmq_stopwatch_stop and zmq_sleep). UUIDs are really important for almost
any non-trivial use of 0MQ, and having one single implementation (that
could be exported to all bindings) makes sense IMHO.
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, 25 August, 2010 09:00
To: zeromq-dev at lists.zeromq.org
Subject: [zeromq-dev] Minor update to zmq_reactor
Folks,
On branch poll_items:
- Updated zmq_reactor_uuid to use a more standard uuid generator.
- Fixed missing endlines, #endifs etc.
No new functionality.
zmq_reactor is being staged into production for a client, it's very
useful. The nice part is you can write a class that looks like this:
class reactor_io {
shared state;
int reactor_inbound( ... ) {
do something
has access to shared state;
}
int reactor_outbound( ... ) {
do something
has access to shared state;
}
...
int poll()
{
setup the reactors[]
do the zmq_reactor_poll() here
return poll result
}
};
Essentially, you wrap the whole reactor framework (=device) in a single
class.
I used a template<> static binding function to remove the muss and fuss
there.
Best,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100825/7671becd/attachment.htm>
More information about the zeromq-dev
mailing list