FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

Il giorno sab, 26/11/2005 alle 11.02 -0500, James K. Lowden ha scritto:
> 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.  
> 

This is how is coded now...

if (tds->query_timeout_func && tds->query_timeout)
   timeout_action = (*tds->query_timeout_func)
(tds->query_timeout_param, now - global_start);

> 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).

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

No problem.

freddy77