[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,
Jarek
More information about the zeromq-dev
mailing list