Re: High CPU shoot during poll retry

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