[zeromq-dev] Polling API

Martin Sustrik sustrik at 250bpm.com
Thu Apr 15 18:43:08 CEST 2010

Martin Lucina wrote:

>> //  Account for both 0MQ sockets and file descriptors.
>> union zmq_poll_item_t
>> {
>>      void *socket;
>>      int fd;
>> };
> Why a union type? Will that not be potentially problematic for some
> languages? 

Yes. More over it is not clear how to distinguish between raw sockets 
and 0MQ sockets.

>> //  Construction & destruction.
>> void *zmq_poller (void *context);
>> int zmq_poller_close (void *poller);
> zmq_pollset_init() seems more consistent (we have zmq_init(),
> zmq_msg_init...())

On the other hand: zmq_socket(). Hm.

>> //  Pollset manipulation.
>> int zmq_poller_mod (void *poller, zmq_poll_item_t item, int events, void 
>> *hint);
> What is this "manipulation" call supposed to do? Shouldn't we have
> zmq_pollset_add() and zmq_pollset_remove() instead?

These seem to be superfluous. First update = add, update with no events 
to return = remove.

>> //  Getting events.
>> int zmq_poller_event (void *poller, zmq_poll_item_t *item, int *events, 
>> void **hint);
> So, "Getting events" is the part that actually performs the poll operation?
> Or is that missing here?

Yes. The point here is to return the events one by one. If there are no 
events to return, it will wait for one. If there is at least one event, 
one of the will be chosen to be returned.

The rationale is as follows:

1. It's easier for the user (including language bindings) to process one 
event at the time rather than having to mess with an array.

2. 0MQ can apply theoretically correct algorithm to choose which event 
is returned.

a. The events for subscriptions that were already removed can be dropped 
behind the scenes.

b. Fair queueing (or similar) algorithm can be applied thus shielding 
the user from issues like giving precedence to a single socket thus 
virtually blocking other sockets.

>> Maybe zmq_pollset would be more appropriate than zmq_poller?
> I vote for zmq_pollset, definitely.

I like 'pollset' better myself.

> Incidentally we seem to be getting close to something similar to the APR
> pollset API, which I have used in anger in the past and I've been pretty
> happy with it.
> For reference: http://apr.apache.org/docs/apr/1.4/group__apr__poll.html

Any concrete suggestions based on APR API?


More information about the zeromq-dev mailing list