[zeromq-dev] Polling API

Brian Granger ellisonbg at gmail.com
Tue Apr 13 22:03:37 CEST 2010


Martin,

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

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

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

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

Cheers,

Brian

> Thoughts?
> Martin
>
> gonzalo diethelm wrote:
>>> Well, I would say that polling is ripe to get some standardised
>>> interface. Something like epoll/kqueue.
>>>
>>> There's one provided by Python binding, now there's Java, Lisp copies
>>> the C interface, not sure about PHP and other languages...
>>>
>>> Thoughts anyone?
>>
>> To get this discussion going, here is an example of how things work in
>> Java now:
>>
>>   // create a 0MQ context that has poll enabled
>>   ZMQ.Context ctx = ZMQ.context(1, 1, ZMQ.POLL);
>>
>>   // create two sockets
>>   ZMQ.Socket spip = ctx.socket(ZMQ.REQ);
>>   ZMQ.Socket smsg = ctx.socket(ZMQ.PUB);
>>
>>   // create a poller for two sockets
>>   ZMQ.Poller poller = ctx.poller(2);
>>
>>   // configure poller to wait forever
>>   poller.setTimeout(-1);
>>
>>   // will poll for INPUT on socket spip.
>>   // ip is the index for sockete spip in the poll set.
>>   int ip = poller.register(spip, ZMQ.POLLIN);
>>
>>   // will poll for OUTPUT on socket smsg
>>   // im is the index for sockete smsg in the poll set.
>>   int im = poller.register(smsg, ZMQ.POLLOUT);
>>
>>   // loop forever; this loop should have a termination clause!
>>   while (true) {
>>       // call poll, possibly block
>>       long p = poller.poll();
>>
>>        // poll may have spurious returns
>>       if (p <= 0)
>>           continue;
>>
>>       // Can we write on smsg? Go ahead.
>>       if (poller.pollout(im))
>>           process_messages();
>>
>>       // Can we read on spip? Go ahead.
>>       if (poller.pollin(ip))
>>           process_pipe();
>>   }
>>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com



More information about the zeromq-dev mailing list