On 12/13/2014 04:48 AM, Gaurav Srivastava wrote:
> We are providing timeout value as 0 or -1 in poll() timeout field meaning
> zero timeout or infinite wait . During zero timeout case poll will
> immediately return with return value as zero and come out of loop.But from
> the places where this api SOCK_wait_for_ready()is called , it is checked
> that return value is 0 or more
>
> if (SOCK_wait_for_ready(sock, FALSE, FALSE) >= 0)
>
> goto retry;
> In case of zero timeout if reading fd is not ready, it will go into
> continuous retries and in case of access load suppose 200k
> registrations,10k calls running it will result CPU to shoot very high.
The above call passes nowait==FALSE. It will wait.
The callers that pass nowait==TRUE look like this:
> if (!maybeEOF)
> {
> int nready = SOCK_wait_for_ready(self, FALSE, TRUE);
> if (nready > 0)
> {
> maybeEOF = TRUE;
> goto retry;
> }
> else if (0 == nready)
> maybeEOF = TRUE;
> }
> if (maybeEOF)
> SOCK_set_error(self, SOCKET_CLOSED, "Socket has been closed.");
> else
> SOCK_set_error(self, SOCKET_READ_ERROR, "Error while reading from the socket.");
> return 0;
On the first iteration, it calls SOCK_wait_for_ready() with zero
timeout, to check if the socket is immediately readable. If it is, it
retries once. Otherwise it throws an error.
> This is the actual problem statement,please let me know if i was able to
> made my point clear.
>
> If yes,then other than putting usleep() before every retry can we provide
> better solution? I solved my issue using usleep
If you can create a test program to reproduce the problem you're seeing,
I can have a look. Or you could attach a debugger and trace through
where it's actually looping.
- Heikki