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

[Michael Haberler]

I have  ZMQ_POLLPRI and ZMQ_POLLHUP working fine so far if poll() is used

however, I see no way to detect a pipe write side hangup with select() without doing a read() in zmq.cpp, which suggests to:

- drop ZMQ_POLLHUP and subsume it under ZMQ_POLLERR as before
- document the behaviour, meaning if a handler reading from a named pipe gets a ZMQ_POLLERR it should attempt a read(); if the read() returns 0 then it was in fact a hangup and the pipe should be closed and reopened, and the poller reestablished with zloop_poller_end () and zloop_poller().

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.

- Michael


Am 25.09.2012 um 12:36 schrieb 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
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev