[prev in list] [next in list] [prev in thread] [next in thread] 

List:       zeromq-dev
Subject:    Re: [zeromq-dev] Can zmq_pollitem_t contain an item with a NULL socket ?
From:       Pieter Hintjens <ph () imatix ! com>
Date:       2014-01-30 19:10:24
Message-ID: CADL5_sh++FAxFsPZ0fjvW3ORN9RuRA1qfZDE+q5T4-WzUM5cxA () mail ! gmail ! com
[Download RAW message or body]

You can't make such a change, anyhow, it'd break our contracts. And
it's pointless to do, just add the abstractions you need in your
language binding. CZMQ has two, for example, zpoller and zloop. If
you're working in C++, invest in the C++ binding.

On Thu, Jan 30, 2014 at 7:22 AM, Laurent Alebarde <l.alebarde@free.fr> wrote:
> 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@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@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@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[prev in list] [next in list] [prev in thread] [next in thread]