[zeromq-dev] ZMQ_POLLIN received on WRITE event

Dorvin dorvin at tlen.pl
Fri Sep 26 09:51:40 CEST 2014

W dniu 2014-09-25 13:54, Goswin von Brederlow pisze:
> It might help if you would post a testcase that:
> a) actualy compiles
It actualy compiles on Windows. I think I should state it more clearly 
in first post.

> b) doesn't involve undefined behaviour:
>         (ii)   select()  may  update  the timeout argument to indicate how much
>                time was left.  pselect() does not change this argument.
>         On  Linux,  select() modifies timeout to reflect the amount of time not
>         slept; most other implementations do not do this.   (POSIX.1-2001  per-
>         mits either behavior.)  This causes problems both when Linux code which
>         reads timeout is ported to other operating systems, and  when  code  is
>         ported  to Linux that reuses a struct timeval for multiple select()s in
>         a loop without reinitializing it.  Consider  timeout  to  be  undefined
>         after select() returns.
Again, it's not undefined on Windows. However, your point is worth 
remembering in case I'll need to port my code in the future. Resetting 
timeval is cheap enough to do it on regular basis on every attempt to 
use select() on any platform. I set nfds (which is ignored on Windows) 
but omitted timeval. I'll remember that.

> All I see is that you use select with 0 timeout, which makes the
> select basically pointless. You also wrongly select the FD for
> writability (which is always possible, so a NOP) and then "break" when
> a message was received. Since messages arrive asynchronously you
> eventually hit the case where a message gets received just at that
> time. Nothing wrong there.
Of course 0 timeout is pointless. The same as using select() on just one 
descriptor. This was naive method to simulate event without actualy 
introducing external library.

Anyway, both of you gave me some valuable input to reconsider 
differences between 0mq and BSD sockets. I still have to figure out some 
elegant way to deal with REQ-REP sockets but it should be easier now.

With regards,

More information about the zeromq-dev mailing list