freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: ZIGLIO Frediano <Frediano.Ziglio AT omnitelvodafone.it>
- To: "'TDS Development Group'" <freetds AT franklin.metalab.unc.edu>
- Subject: Re: Bug in read.c
- Date: Mon, 27 May 2002 14:45:48 +0200
>
> > 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.
> >
>
> Not necessary, or shouldn't be. If there's no data available then a
> blocking read should block (which doesn't eat CPU) and a
> nonblocking read
> should return EAGAIN. In my case it's blocking so it should
> block until
> data arrives. The fact that it returns 0 immediately tells
> you that the
> connection has been broken/closed and you should close the socket.
>
> Scott
>
Also when not-blocking this mean a timeout, you should also reset
connection...
I'm also rewriting select code (they use a bad method and can waste a lot of
cpu-time).
freddy77
-
Bug in read.c,
SMASKELL, 05/23/2002
- <Possible follow-up(s)>
- Re: Bug in read.c, martin dempsey, 05/23/2002
- Re: Bug in read.c, Jon Pounder, 05/23/2002
- Re: Bug in read.c, SMASKELL, 05/23/2002
- RE: Bug in read.c, Matt Kynaston, 05/27/2002
- Re: Bug in read.c, ZIGLIO Frediano, 05/27/2002
Archive powered by MHonArc 2.6.24.