[zeromq-dev] Twisted integration, part 2: review
nicholas at nichol.as
Mon Jun 7 18:24:06 CEST 2010
On Jun 7, 2010, at 4:45 PM, Brian Granger wrote:
>> 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.
> But, IIRC, zmq uses EPOLL underneath the hood when available. Another
> way of putting this is that the built in zmq polling mechanism is
> similar to the Twisted reactor in that it will use the best underlying
> polling API for the platform. Maybe it could be improved or new
> polling mechanisms could be added, but in my mind, the idea is that
> just using it will give you the best option. Both PyZMQ APIs simply
> wrap what zmq itself does.
It will certainly be the best option if you are using just 0MQ sockets. However, polling for non-0MQ sockets using 0MQ poller will give you a significant performance hit compared to fe epoll. I saw a performance degradation of about 30% in a benchmark a while back when i switched from using epoll to 0MQ's poll. By using 0MQ's poller you will also loose poller-specific functionality. Already in epoll's case you will miss options such as switching between edge/level triggers or polling specifically for urgent read data.
On Jun 4, 2010, at 11:06 PM, Martin Sustrik wrote:
> Yet once more on a different topic: I still think creating a wrapper
> library on top of 0MQ that would expose 0MQ via POSIX socket API would
> solve lot of problems (including the twisted case) -- simply because 0MQ
> sockets would become standard file descriptors, there would be no need
> for 0MQ-specific zmq_poll, standard poll/select could be used instead
> Am I still the only one who thinks this idea makes sense?
I do agree that having 0MQ sockets behave as Berkeley sockets would be nice to have and could solve the problem. But i am not sure if it is worth the effort and if it is future proof. I can imagine that somewhere in the future 0MQ has the option to prioritize certain sockets. This would be difficult to handle when all you have is a bunch of fd's which are returned from your call to WHATEVER_POLL.
I think all what is needed is a single signal fd per 0MQ context which can be polled in an external poller and be followed by a 0MQ poll when something interesting has happened. I believe the patch by Serge Aleynikov already enabled this functionality in zmq_getsockopt (zmq_waitfd).
I would love to see this functionality being added to the trunk.
More information about the zeromq-dev