FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Freddy, 

Thanks for net.c 1.62.  I'm a little uncomfortable using tds->s as the
count of open descriptors, but I'm glad we're selecting correctly.  

ZIGLIO, Frediano, VF-IT wrote:
> > > ***************
> > > *** 679,683 ****
> > >              case TDS_INT_TIMEOUT:
> > >                  tds_send_cancel(tds);
> > > !               continue; /* fixme: or return? */
> > >              default:
> > >              case TDS_INT_CANCEL:
> > > --- 670,675 ----
> > >              case TDS_INT_TIMEOUT:
> > >                  tds_send_cancel(tds);
> > > ! // brent 21-May-07 - Return fail seems more sensible then continue
> > > !               return 0;
> > >              default:
> > >              case TDS_INT_CANCEL:
> 
> I realize just now that for writing it's a bit different... we are not
> able to send a packet so we send another cancel packet?? Not that
> clever, probably even sending this packet fails. So or we decide to
> close connection or we wait indefinitely. 

No.  If we can't write, tds_select returns <0 and tds_goodwrite sends
TDSEWRIT to the error handler:

    } else if (rc < 0) {
        [...]
            tdserror(tds->tds_ctx, tds, TDSEWRIT, sock_errno);

> If server close connection for
> some problems we have a write failure, here timeout means that server
> isn't reading our request. This also means that we are not waiting for a
> reply but connection was idle before sending so server is VERY busy at
> the moment.

If the write times out, tds_goodwrite sends TDSETIME to the error handler
and the *application* decides (via the handler's return code) whether or
not to try again.  It's up the the application when to stop trying.  

When reading the above code, it's important to remember that tdserror
consults the client library's error handler, and that db-lib and ct-lib
allow the application to install a handler that they consult.  The return
code -- TDS_INT_TIMEOUT or TDS_INT_CANCEL -- is an instruction from the
handler on how to proceed.  From the library's perspective, there's no
"sensible" or "stupid" choice; there's only the duty to adhere to the
application's wishes.  That means sending the cancel packet when so
instructed, and waiting -- indefinitely, if need be -- for the server to
honor it.  The application gets a chance to change its mind every
query_timeout seconds.  If it doesn't, it's not libtds's "fault".  It's
the application's (if fault there be).  

On TDS_INT_TIMEOUT tds_goodwrite must not return.  It waits, full stop. 
All else is error.  

Kind regards, 

--jkl