> On Wed, Mar 11, 2015 at 1:41 PM, Roberto De Ioris <[email protected]> > wrote: >> I suppose you are doing some kind of stress test. On high load it could >> happen read() returns EAGAIN even if the poller signaled there is >> something to read (in such a case you need to pool again) >> >> It is a very rare condition and i am not quite sure this is the case or >> you have faced some bug. But yes your usage is right. Let me know > > Actually, this happens when just utilizing one core. ^_^ I was > having issues in the past because I would just do a blocking read on > the fd (if it wasn't -1) because I assumed that there was always > something to read. I've changed it to do a non-blocking read and to > loop until I get an EAGAIN. > > The fd I'm using is a 0MQ socket (a SUB to be exact), so perhaps > there's some issue there. I looked to see if anything was being sent > on the socket (in the cases where it returns right away), but I don't > see anything. So, I think I'm properly getting the EAGAIN because > there's nothing to read, but the suspend is returning prematurely. > > 0MQ provides it's own "poller" instead of using epoll or such, so I'm > guessing there's a reason behind that somewhere. >
zeromq exposed file descriptor is edge triggered (you should find a bunch of reference about it in the docs). So you must continue to read until there is nothing more to read. Only after you are sure the queue is empty you can start polling it again. This means you will not get a new poll event (even if there is some message in the queue) if for that "round" an event has already been generated. -- Roberto De Ioris http://unbit.com _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
