[zeromq-dev] Polling API

[Martin Sustrik]

Martin,

>>>> //  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.
> 
> Right, so we agree this would be better off as a plain struct, with the
> same semantics we have for zmq_pollitem_t currently: ->socket takes
> precedence over ->fd?

It's ugly, but I cannot think of anyting better.

>>>> //  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.
> 
> A single call seems unnecessarily terse to me and reminiscent of the
> various UNIX "ioctl" evils. My arguments against are that a) we don't need
> to prefer less calls over clarity b) people understand "add" and "remove"
> as exact operations.

What I am worried about are different corner cases: What if update 
specifies no events? Will the socket remain in the pollset? What if we 
try to remove it afterwards? Should is succeed or cause an error? etc.

Semantics of a single _ctl function are clear on the other hand and _add 
  & _remove can be trivially implemented as wrappers on top of it.

>>>> //  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 you write is all good, but if the call is doing a poll/wait then
> let's make it explicit as either zmq_pollset_poll() or zmq_pollset_wait().
> Also, it needs a timeout parameter.

I've already mentioned _wait. It has a precedent with epoll_wait at least.

Martin