[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