On 12/17/2014 07:21 AM, Gaurav Srivastava wrote:
> 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.
Ok. Well, all I can say to that is "don't do that". There isn't anything
wrong with SOCK_wait_for_ready, as it's used in unmodified psqlodbc.
One idea is to have a separate watchdog thread or alarm signal handler,
and if an operation takes longer than you tolerate, have the watchdog
thread forcibly close() the socket. That will wake up the thread blocked
on the socket. You'll still need to hack psqlodbc to get the file
descriptor of the socket so that you can close() it, but it seems less
risky.
- Heikki