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. _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
