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