[zeromq-dev] zmq_poll versus zloop reactor: different semantics - how to resolve?

[Michael Haberler]

I am heading towards a solution, but it involves more than just conditionally ignoring POLLERR in zloop.c - that's easy (new ZMQ_IGNERR flag in pollitem.events and handling code).

The tough cases involve zmq.cpp - the revents coming back are too aggregated to handle these cases properly; currently every flag in revents which isnt a POLLIN|POLLOUT is returned as a ZMQ_POLLERR.

The missing ZMQ_POLL* bits are:

POLLHUP: this is signaled when a named pipe write side is closed, and zloop was monitoring the read side. Can only be handled by closing/reopening the fifo.
POLLPRI (OOB data): signaled by a kernel sysfs_notify() operation on a sysfs path. Can be handled by doing an lseek(fd,0,SEEK_SET) and read(fd,..) without closing/reopening.

To handle those, I'd #define ZMQ_POLLPRI and ZMQ_POLLHUP as bits if the underlying platform has them, else zero

However, there's a user-visible API change because the definition of ZMQ_POLLERR changes to:

revents & ~(POLLIN | POLLOUT | POLLPRI | POLLHUP)

meaning: a POLLHUP or POLLPRI on the underlying fd so far reported ZMQ_POLLERR; it will post-change report separate ZMQ_POLLHUP and ZMQ_POLLPRI bits instead of ZMQ_POLLERR. Also, code which uses these bits on a Unix platform will fail on, say, Windows, which I cant test here.

---

still want me to go ahead with this? I cant quite judge the impact of this change. I'm happy to do the changes, test for Linux, document them and add a test program. 

- Michael

ps: I said 'I did the prototype with libzmq - which worked fine' which in reality wasnt the case.

Am 24.09.2012 um 21:41 schrieb Pieter Hintjens:

> On Mon, Sep 24, 2012 at 2:00 PM, Michael Haberler <mail17 at mah.priv.at> wrote:
>> I have an application where a named pipe, and a sysfs device is monitored. I did the prototype with libzmq - which worked fine - and the switched to czmq, which broke things for me.
>> 
>> the issue is: czmq is too agresssive in shutting down a poll handler if a POLLERR is returned.
> 
> Could be.
> 
>> I dont like it, but am unsure what to do; fiddling with the inner loop of the reactor I dont feel confident about yet.
> 
> It's a little involved but not so complex so my advice would be to
> look at the internals, propose a patch.
> 
> You do want to provide a test case so people can see the before/after results.
> 
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev