> I'm doing some work with ugreen that I think it's relatively simple
> and straightforward, but I'm still a little confused about how it
> appears to be working.  I have code like this:
>
>     uwsgi.wait_fd_read(fd, timeleft_seconds)
>     uwsgi.suspend()
>     ready_fd = uwsgi.ready_fd()
>
> My understanding of from using other polling methods is that the
> uwsgi.suspend() should return on one of two conditions:  1. fd has
> something to read on it, or 2. the timeleft_seconds has elapsed.
>
> However, I'm seeing cases where it returns nearly immediately after
> calling suspend() and it's neither case:
>
> core96: wait 49 seconds on fd 23
> core96: suspended for 0.000261 seconds
> core96: returned fd: 23
> core96: break on EAGAIN (nothing to read on fd)
> core96: wait 49 seconds on fd 23
> core96: suspended for 48.099486 seconds
> core96: returned fd: -1
>

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

-- 
Roberto De Ioris
http://unbit.com
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to