[zeromq-dev] zmq_poll versus zloop reactor: different semantics - how to resolve?
mail17 at mah.priv.at
Thu Sep 27 22:23:52 CEST 2012
Am 27.09.2012 um 19:11 schrieb Pieter Hintjens:
> On Tue, Sep 25, 2012 at 3:51 PM, Michael Haberler <mail17 at mah.priv.at> wrote:
>> In summary, this would mean that libzmq and czmq can detect and support OOB data on a file descriptor with zloop() as well as zmq_poll(), and deal with sysfs notifications and named pipes properly.
> So no API change, than?
no, except for the czmq polleritems flag to 'disable disabling' of the reactor callback
As for the aggregation of pollitem flags: returning other bits with finer granularity requires a major safari through the zmq select/poll/epoll zoo, and it is bound to break some uses. For my use case, I found a way to deal with the aggregation by more resilient testing in the reactor callback.
> It's a somewhat esoteric case (thus the silence from others on the
> list, I think).
background: the application would be such that both user processes as well as kernel modules can be originators and recipients of messages; ontop of that there's a simulator mode where the kernel modules are compiled with different flags and become userland DSO's - read as: a consistent messaging interface for that setup is hard to come by.
I think I'll drop named pipes and sysfs, and settle for generic netlink sockets; they work fine with zloop and kernel modules so far and they can be used with uniform adressing kernel/userland as well as user/user which helps with the above setup. I guess I'll add an example for that when I'm done - the documentation on netlink use is a bit impenetrable and there are hardly any good examples.
> But if you feel this is a good design, make the pull
> request and we'll merge it. As long as it doesn't break existing apps.
I dont think the ZMQ_IGNERR attribute will do damage (yeah right;)
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev