Re: High CPU shoot during poll retry

Hi Heikki,

Just to explain a bit more about the case "nowait==FALSE"

We used this fix "Rip out broken retry/timeout logic in
SOCK_wait_for_ready" as in few scenarios our clients also get stuck in
infinite wait and our design is such that none of our process can wait
little longer than few secs if this happens preventive actions are taken
resulting re-initialization of the process.

In order to avoid that wait situation we did slight modification i.e.
making "nowait" TRUE everywhere in SOCK_wait_for_ready() API which resolved
our poll() wait issue after your fix,thanks for that but later to that this
high CPU issue has come.

We resolved it using micro sleep,but still looking for a better solution,as
we don't have much understanding of ODBC.

Please let me know if I am not clear or you require more information.

Thanks and Regards,
Gaurav Srivastava | Associate Consultant
GlobalLogic
P +91.120.4342000.2920 M +91.9953996631 S ta5ramn1
www.globallogic.com
<http://www.globallogic.com/>
http://www.globallogic.com/email_disclaimer.txt

On Tue, Dec 16, 2014 at 8:23 PM, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com
> wrote:
>
> 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
>
>