Skip to Content.
Sympa Menu

freetds - Re: [freetds] Timeout for reading from the server doesn't work.

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: entropy AT freetds.org
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Timeout for reading from the server doesn't work.
  • Date: Sat, 26 Nov 2005 16:41:58 -0500

James K. Lowden wrote:
Frediano Ziglio wrote:

We do not yet have a reliable way to do this, because each client
library has its own convention for handling timeouts. Db-lib and
ct-lib expect different error codes and return different values (and
have different semantics). Meanwhile, libtds does not know which
client library established the connection, and thus cannot know what
semantics to use. The solution to *that* is to create a consistent
interface to libtds, and let it call out to the client library, which
will in turn invoke the handler and return a consistent error code to
libtds. Obviously, a first step would be to modify TDSSOCKET to
record the client library in use.

Whatever library all libTDS has to know is how to behave in timeout
situations... this should be possible using current timeout callback.
IMO what should be revised and tested should be dblib/ctlib behavior
(dblib particularly).


Agreed. Keep in mind that the application's handler will be different,
depending on whether it's db-lib or ct-lib. The rules are different, even
though at the tds layer it all boils down to retry/abort. That's why each
library needs its own intermediary to interpret the handler's return code
and convert it into libtds's single form. To do that, libtds has to know
which intermediary to call.
application
API library
libtds
goodread (or whatever)
error
determine API
API intermediary
application's error handler
convert API return code to libtds code
retry or abort

I hope that's clear. Tell me if not.

I agree with Freddy. The API return codes should never leave the API and its applications. All interfacing to libtds should be done in the callback routine that the API registered with libtds. Then there is no need for libtds to know or care which API is involved, and it doesn't need to be polluted with API-specific codes. The "API intermediary" should be provided by the API itself, and all libtds then needs to do is call it.

--
Cheers,
entropy




Archive powered by MHonArc 2.6.24.

Top of Page