[zeromq-dev] Twisted integration, part 2: review
Laurens Van Houtven
lvh at laurensvh.be
Fri Jun 4 20:13:59 CEST 2010
On Fri, Jun 4, 2010 at 7:41 PM, Nicholas Piël <nicholas at nichol.as> wrote:
> On Jun 4, 2010, at 6:31 PM, Laurens Van Houtven wrote:
> Hi Laurens,
> I quickly summarize the 4 possible different approaches as you suggested.
> 1. Implement everything in Python
> 2. Write a new thin layer to the C++ API
> 3. Use PyZMQ's provided select
> 4. Use PyZMQ's Poll as a reactor
> I agree with your reasoning that option 1 isn't really an option. Nor is option 2, why go duplicating the work already done on PyZMQ. PyZMQ follows 0MQ well and has a pretty thorough test suite.
Yay, glad to hear that resonates with someone else somewhere too.
> So, i really believe option 3 and option 4 are the only viable options. I am not so sure if it is a good idea to disregard option 4 at this point. Ie, doesn't Twisted already have the option to choose an EPOLL reactor? I think a reactor based on ZMQ's Poll would be a fine substitute for people just wanting that kind of integration. I am currently doing this in my current approach (a Stackless Python based event loop around 0MQ's poll).
> While I would prefer to have my main event loop based around regular EPOLL (for performance reasons) it is difficult to combine them at the moment as you have to handle two different pollers at the same time. There is no way to get a signal from ZMQ yet to easily integrate it in an external event loop. Thus i don't think option 3 is a viable option at this moment, you could do it but you would basically end up with something that looks like busy looping a non blocking PyZMQ select or blocking the Twisted event loop. There has been some discussion on the mailing list so i expect that features that will make this possible in the correct way will probably be added in the near future.
Twisted currently has a ThreadedSelectReactor that basically runs
multiple selects in different threads (usually one thread and one
select). The idea is to run zmq.select in a second thread or have it
replace select.select entirely. It's not very good but it's not very
bad either :)
> What you could do, for now, is have ZMQ be your main poller, option 4, and than have it also poll for the signal fd of the other poller. Epoll for example, has an fd which is pollable i can imagine that the other reactors have something similar. Another approach is to have the two pollers run in separate threads, but you would still need inter-thread communication for that which will add to the latency.
That would be pretty good, but the problem is that epoll/kqueue/...
are separate reactors in Twisted at the moment, so you'd need separate
integration with each one. That doesn't sound like a good thing. I'm
not sure if Twisted can be fixed in this respect: I know that people
don't like the way it (ThreadedSelectReactor) works now, but to quote
a very smart man: "it sucks, but everything else we tried was way
> But, I think the best would be to wait a little bit before throwing this at the Twisted community until ZMQ's Poller/Pollset/wait_fd interface has had a little more thought (and preferably has been implemented). Not only would this open the road to option 3, but I also think it would otherwise be difficult to have a decent discussion with a large group of people when the interface in question is still in flux.
Yes, integrating the two event loops would be awesome.
Thanks for your input,
More information about the zeromq-dev