FreeTDS Development Group

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

ZIGLIO, Frediano, VF-IT wrote:
> > I use this great library (libtds) to communicate with MSSQL 
> > server on an
> > embedded system. It's rather important that this system never stops
> > sending data for a longer period of time. But as far as I 
> > could observe
> > this occurs every time the server becomes unreachable. In both the
> > stable release and the CVS version a timeout can be set for this case,
> > but in the stable version this triggers an assertion and in the CVS
> > version as far as I understand the code it leads to an infinite loop.
> > For the latter case there is a rather simple fix which makes the
> > goodread function abort instead of waiting forever. I only insert data
> > into the database but this has worked reliably now for the 
> > last 4 days.
> > 
> Opss... please ignore my previous mail. len == 0 means select timeout or
> connection close (recv returned 0) so IMO the best way is to detect
> connection close in side if ((len = select... and close connection
> correctly.

Well, it won't be the last time this code is patched.  ;-)

Timeouts should invoke the error handler, calling the user-installed
function.  The application can then return a code indicating whether to
retry or cancel the operation.  

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.  

I worked on this over the summer but haven't been able to return to it, no
pun intended.  

--jkl