[zeromq-dev] Polling API

Martin Sustrik sustrik at 250bpm.com
Wed Apr 14 11:21:09 CEST 2010


Hi Brian,

>> What I rather had in mind was how to move most of the functionality
>> directly to C API. If C API provides most of it, it would be much easier
>> for bindings to wrap it and - additionally - it would ensure exactly the
>> same behaviour for all the languages.
> 
> OK, this makes more sense.
> 
>> Here are my thoughs:
>>
>> 1. The current API - although it matches POSIX poll - is not good
>> because passing arrays of structures to and out of zmq_poll is not
>> trivially mimicked by other languages.
> 
> Yes, the arrays and structs are annoying.
> 
>> 2. The API should provide a 'poller' object (as currently done in most
>> language bindings) and individual associated functions
>> (adding/modifying/removing sockets, getting events etc.) should be
>> prototyped in a way to require only simple types as arguments.
> 
> Yes, I like this idea.  This would make the C API pretty similar to the Poller
> object in Python actually.

Ack.

> 
>> 3. Poller object should be initialised from context object - the point
>> is that even when there's no 0MQ socket in the pollset, just standard
>> POSIX sockets, we still want the poll to exit when context is destroyed
>> (ETERM).
> 
> Yep, sounds right.  Also, this enables us to do checks to make sure that
> a given poller object only handles events from sockets that belong to that
> context.

Exactly.

>> 4. Adding/removing/modifying items in the poll set can be presumably
>> done by a single function. If the socket is not yet in the pollset it
>> will be added, if the IN/OUT/ERR flags match the current item in the
>> pollset, they will be modified. If there's none of the flags set, the
>> socket will be removed from the pollset.
> 
> Sure, that sounds fine.
> 
>> 5. I am not sure how retrieving events should work, however, experience
>> with similar interfaces (epoll/devpoll/kqueue) seems to indicate that
>> the event returned should contain:
>>
>> a.) the socket
>> b.) the event (IN/OUT/ERR)
>> c.) a hint (arbitrary object attached to the pollitem)
> 
> Sounds good, I don't see really any other way of handling this.

I don't like the idea of returning a struct, however, I see no way to 
avoid it at the moment.

>> Presumably, the events should be retrieved from the poller one by one
>> rather than as a set.
> 
> Do you mean socket, event, hint triplet should be retrieved one by
> one?  I don't mind them
> coming back as an array of structs but maybe that is tough for some
> lanuages.  Either
> way is fine for me on this part.

There are two point to this IMO. First is the fact that returning an 
array of structures is not trivial and may cause (performance?) problems 
in some language bindings.

The second point is that that way 0MQ will be responsible for 
ordering/filtering the events. That way we can avoid some common 
mistakes associated with polling, like unfair handling of individual 
sockets - say while the first socket in the pollset is active other 
sockets will never have a say etc.

Martin



More information about the zeromq-dev mailing list