[zeromq-dev] ZMQ_POLLIN received on WRITE event
Goswin von Brederlow
goswin-v-b at web.de
Fri Sep 26 10:39:57 CEST 2014
On Fri, Sep 26, 2014 at 09:51:40AM +0200, Dorvin wrote:
> 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.
With the includes for FD_SET missing and Sleep() undefined?
> > 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
MfG
Goswin
More information about the zeromq-dev
mailing list