On Thu, Apr 15, 2010 at 9:58 AM, Martin Lucina <m...@kotelna.sk> wrote:
> sust...@250bpm.com said:
>> 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.
>
> 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?
>
>> >> // 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.
>
> I have no opinion, just a suggestion :-)
>
>> >> // 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.
I guess I like the add, remove language.
>> >> // 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.
I am assuming there will continue to be a timeout though?
> 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 like poll rather than wait.
>> I like 'pollset' better myself.
>
> Good, we agree.
>
>> > 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?
>
> What I write above is based on my experience with that API. They use
> apr_pollset_add(), apr_pollset_remove() and apr_pollset_poll().
>
> -mato
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@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
bgran...@calpoly.edu
elliso...@gmail.com
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
