[zeromq-dev] Twisted integration, part 2: review

Martin Sustrik sustrik at 250bpm.com
Mon Jun 7 19:03:51 CEST 2010


Hi Nicholas,

> 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 
platform).

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.connect ("tcp://services.google.com:7890");
s.setsockopt (PRIORITY, 2);
s.connect ("tcp://services.bing.com:7890");

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
> (zmq_waitfd).
> 
> 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 
read/written.

Martin



More information about the zeromq-dev mailing list