[zeromq-dev] Can zmq_pollitem_t contain an item with a NULL socket ?

[Laurent Alebarde]

Forget it. I won't make such change. It would be too much work for a 
risky result. The benefit would have been to be able "/to build 
zmq_pollitem_t arrays with more ease, when they are built by the 
application itself, and not hardwritten in the code./"


Le 30/01/2014 13:29, Lindley French a écrit :
> No particular objection to the union idea (although it should be 
> carefully profiled for speed against the existing code!) but I am 
> curious, what possible benefit there could be to have NULL sockets in 
> the poller? This seems contrary to "expected" workings in C-like 
> languages.
>
> On Jan 30, 2014, at 5:20 AM, Laurent Alebarde <l.alebarde at free.fr 
> <mailto:l.alebarde at free.fr>> wrote:
>
>> IMHO, it is a bad design of zmq_pollitem_t. It should not have one 
>> attribute for socket and another one for file-descriptor with this 
>> unrobust behaviour to use the second one when the first one is NULL, 
>> but one for the type (socket or fd), and a union containing one or 
>> the other.
>>
>> Implemented:
>> typedef struct
>> {
>>     void *socket;
>> #if defined _WIN32
>>     SOCKET fd;
>> #else
>>     int fd;
>> #endif
>>     short events;
>>     short revents;
>> } zmq_pollitem_t;
>>
>> Should be:
>>
>> typedef struct
>> {
>>     int type; // ZMQ_SOCKET | ZMQ_FD
>>     union {
>>         void *socket;
>>         #if defined _WIN32
>>         SOCKET fd;
>>         #else
>>         int fd;
>>         #endif
>>     } dev;
>>     short events;
>>     short revents;
>> } zmq_pollitem_t;
>>
>> But it would break the ABI to change it, isn't it ?
>>
>>
>> Le 30/01/2014 10:56, Laurent Alebarde a écrit :
>>> In fact, it is in src/zmq.cpp / "int zmq_poll (zmq_pollitem_t 
>>> *items_, int nitems_, long timeout_)"
>>>
>>> When the socket is NULL, zmq_poll takes the second attribute of the 
>>> zmq_pollitem_t structure which is a file descriptor. So, I cannot do 
>>> anything here, as "socket == NULL and fd == 0" is legitimate.
>>>
>>> Conclusion: I have to deal myself with the complexity of not having 
>>> NULL sockets in my zmq_pollitem_t array.
>>>
>>> Le 30/01/2014 09:23, Laurent Alebarde a écrit :
>>>> Thanks Pieter.
>>>>
>>>> Personnaly, I would prefer "ignore", in order to build 
>>>> zmq_pollitem_t arrays with more ease, when they are built by the 
>>>> application itself, and not hardwritten in the code.
>>>>
>>>> Any objection ?
>>>>
>>>> Le 29/01/2014 20:20, Pieter Hintjens a écrit :
>>>>> Undefined, by the man page. It should probably assert in such a case.
>>>>>
>>>>> On Wed, Jan 29, 2014 at 12:07 PM, Laurent Alebarde<l.alebarde at free.fr>  wrote:
>>>>>> Hi Devs,
>>>>>>
>>>>>> What is the zmq_poll behaviour when the zmq_pollitem_t array contains an
>>>>>> item with a NULL socket ? ignored, undefined, error ?
>>>>>>
>>>>>> If it is in src/poll.cpp / "void zmq::poll_t::loop ()" / "for
>>>>>> (pollset_t::size_type i = 0; i != pollset.size (); i++)", it seems there is
>>>>>> no NULL test with a continue.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>>
>>>>>> Laurent
>>>>>>
>>>>>> _______________________________________________
>>>>>> zeromq-dev mailing list
>>>>>> zeromq-dev at lists.zeromq.org
>>>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>>
>>>>> _______________________________________________
>>>>> zeromq-dev mailing list
>>>>> zeromq-dev at lists.zeromq.org
>>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> zeromq-dev mailing list
>>>> zeromq-dev at lists.zeromq.org
>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140130/1da86167/attachment.htm>