FreeTDS Development Group

[Jon Pounder <JonP AT inline.net>]

when I get read of 0 bytes, I usually do a select(...NULL..., timeout) to 
pause for a predetermined amount of time without chewing up cpu, to allow 
more data to arrive.

if the socket is broken, and not just out of data, check for that condition 
with a select and error conditions setting.


At 09:04 AM 5/23/2002 -0500, you wrote:
> There appears to be an error in read.c that bit me the other day.  I got a
> call from the Unix police saying that my processes were eating all of the
> CPU.  I connected to them with gdb and found that they appeared to be stuck
> in a read() loop.  There had been a network outage and my programs'
> connections to their db servers had been dropped, apparently precipitating
> the problem.  Looking at the source for goodread() in read.c it appears
> that there is no allowance made for the read() call returning 0.  If a
> socket read, blocking or not, returns 0 it is an indication that the socket
> connection has been closed/broken.  This was the case in my situation.
> Since read did not block and returned 0 immediately, the function looped
> continuously.
>
> It looks like you could just change line 77 of read.c from:
> if (len < 0) {
>
> to:
> if (len <= 0) {
>
> That would catch read() returning 0 and assume the socket was broken.
>
> Opinions?
>
> Thanks
> Scott Maskell
>
>
> ---
> You are currently subscribed to freetds as: [pounder AT inline.net]
> To unsubscribe, forward this message to 
> $subst('Email.Unsub')