[nanomsg] Re: Survey pattern and polling

  • From: Martin Sustrik <sustrik@xxxxxxxxxx>
  • To: <nanomsg@xxxxxxxxxxxxx>
  • Date: Thu, 14 Feb 2013 13:55:38 +0100

On 2013-02-14 13:20, Dirkjan Ochtman wrote:
On Thu, Feb 14, 2013 at 12:30 PM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:

The question is how shoud the timeout be reported when the socket is
polled on? Signalling POLLERR would mean that any subsequent polling on the socket -- even for POLLOUT would fail (according to POSIX there's no way to disable reporting POLLERR). Signalling POLLIN is kind of strange given that
subsequent recv() will return EFSM error.

Ideas anyone?


I think signalling POLLIN makes sense in this case; EFSM seems to also be a kind of incoming event (even though it's not really incoming). You should
be sure to clearly document it in both the poll and survey pattern
documentation, though.

The strange thing about POLLIN is that in this case the event is reset by calling send(), ie. by launching new survey, rather than by recv() as is the case elsewhere.

Anyway, I think you are right, it would work with POLLIN. The scenario would look like this:

1. poll for in
2. in is signaled
3. recv() => EFSM
4. stop polling for in (although it is still signaled thanks to lingering EFSM error)
5. start polling for out (new survey)
6. out is signaled
7. send new survey
8. at this point IN is no longer signaled as EFSM error is cleared by new survey
9. poll for in (to get first survey response)
10. recv()
etc.

Ah, btw, I've just thought of a different related problem: How to exit blocking poll() or select() when the library is being terminated (nn_term)? It looks like ZeroMQ doesn't do this right. We'll probably need a special POLLERR event to be signaled even if the user is not polling for POLLIN or POLLOUT.

Martin

Other related posts: