[zeromq-dev] Twisted integration, part 2: review
sustrik at 250bpm.com
Mon Jun 7 19:03:51 CEST 2010
> 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.
The 30% may be bacause zmq_poll internally uses poll instead of epoll
(while I/O threads use select/poll/devpoll/epoll/kqueue depending on the
It may be interesting to make zmq_poll use epoll internally, however,
that would require different API. It was already discussed on the list.
>> 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 etc.
>> 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.
Well, that's the nature of poll. It returns _all_ the events. User
should choose which of them to handle and in what order.
As for prioritisation in 0MQ I would rather imaging something like this:
s = ctx.socket (REQ);
s.setsockopt (PRIORITY, 1);
s.setsockopt (PRIORITY, 2);
Requests sent to the socket would then go to the Google in the first
place, however, if Google is unavailable they'll be passed to Bing.
> 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
> I would love to see this functionality being added to the trunk.
Yes. That's the next thing I am up to.
However, you have to take into consideration that the fd will signal
POLLIN if _anything_ happens with the socket. Afterwards you'll have to
invoke zmq_events (s, &revents) to find out whether messages can be
More information about the zeromq-dev