[zeromq-dev] Non-blocking calls and Twisted

Brian Granger ellisonbg at gmail.com
Tue Apr 13 21:48:56 CEST 2010


>     1. ThreadedSelectReactor (aka DreadedSelectReactor,
> DreadfulSelectReactor, TerribleSelectReactor and TorturedSelectReactor),
> hereafter abbreviated to TSR

I agree that this is not a great way to go...

>     2. Reimplement ZMQ in Python/Twisted (I've picked up this is what the
> Erlang bindings did?)

I think there is a 3rd route.  Why not just implement a new reactor
from scratch that
looks something like the existing poll reactor?  The Poller class in
pyzmq has the
exact same API that Python's select.poll does, so I don't see the
problem.  Am I missing
something.  This is what I would look at.

> Writing a custom reactor, while it would work, is suboptimal because it
> would disable mainloop integration with stuff like Qt, Gtk... (mostly GUI
> event loops). The only remaining problem is that you couldn't use the stuff
> Twisted supports outside of select() calls (epoll on Linux2.6, kqueue on
> BSD, IOCP on win32), because you can only use exactly one reactor (well,
> sort-of, but that would get us into way more detail than we probably should
> here), and TSR doesn't do any of those things.

The Qt, Gtk, etc. integration could be handled in the same way it is
now (unless I really am missing something).
Just create a subclass of the ZMQReactor class that adds the GUI event
loop stuff.

But zmq_poll already uses the best available underlying polling
mechanism on each platform if I understand
correctly.  In other words, zmq_poll already provides a unified
interface to select/poll/epoll/.etc.
If it doesn't then we should work with Martin so that it does.

> The only way to retain them ({epoll, kqueue, iocp}) would be to ignore
> ZeroMQ's current implementation of it.

This is not an option as I understand it.  You will end up seeing the
tcp sockets that underly the actual zmq socket
and will have to sort out the mess.

> I don't really understand ZeroMQ's
> internals yet, so I'm not really sure how much of it could be reused
> (although presumably quite a bit, through Cython).

I don't think you want to do anything that relies on the internals of zmq.

> Twisted will happily give
> you bytes and pretend everything's a stream, so TCP would be fairly easy to
> implement. I don't think interthread/IPC would ever work -- IPC might,
> interthread would just be ugly (and threads are mostly an anti-pattern in
> Twisted code to make up for silly things that don't have async interfaces
> anyway). Twisted does do multicast, but AFAIK it doesn't do RFC 3208 PGM.
> So, you could write Cython extensions that call the C++ code, but I'm not
> sure where to tap in to it and just how well that would work, mostly because
> I know nothing of 0MQ's C++ internals. Additionally, I'm just looking at ZMQ
> because we're using AMQP in production now and I wanted to see what all of
> the fuss is about, six-months-in-the-future-me maintaining something that he
> started writing six months ago because of a piece of software he used for a
> week is not a good place for future-me to be :-)

Another thing to remember.  A huge advantage of using zmq itself is
that it does alot
of work in separate threads (C++), which allows you to do a lot
without worrying about the GIL.
One of the reasons we are using zmq for our python projects is that
twisted is slow when you try to add
all the complex queueing logic and can't take advantage of multiple cores.

> Like you said, binary protocols are easy, queuing is hard, best case
> scenario we can keep both. Where exactly does the code stop requiring real
> sockets and does it become happy with bytestrings?
> tia
> lvh



Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com

More information about the zeromq-dev mailing list