FreeTDS Development Group

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

All, 

As previously announced, I'm working on new timeout logic.  Tonight I
committed some of it, but I want everyone to know it's not done yet.  Like
most such things, it will get worse before it gets better.  

Freddy, I would especially like your opinion on a new function:
net.c::tds_select().  

It's not called by anything yet, so it can't do any harm.  The idea is to
localize all the timeout logic in one place.  (I started to add it
wherever we could wait for the network.  That was too messy, as you can
still see, because I haven't backed it out yet.)  

The idea is libtds needs to be able to call back to the client library for
two purposes:

1.  While waiting for a read from the server (cf. dbsetinterrupt).
2.  When the user-defined timeout expires (cf. dberrhandle)

The callback routines determine what libtds should do.  Docs say
dbsetinterrupt applies only to reads.  Not sure why writes wouldn't apply,
too.  

The error handler can return INT_TIMEOUT, meaning "send a cancel packet to
the server and wait for it to be acknowledged."  Of course, the cancel
might never be acknowledged, and that read might timeout.  This leads to a
weird kind of recursion:

1.  dbnextrow()
2.  timeout, call tdserror()
3.  tdserror() returns TDS_INT_TIMEOUT
4.  libtds sends cancel packet
5.  libtds waits for cancel to be acknowledged
6.  timeout, call tdserror()
7.  goto #3.  

I thought at first we should try to prevent this.  But on reflection I
don't think so.  I'm not sure how the server would respond to receiving
two cancel packets.  But libtds can't know if the first (or Nth) cancel
packet was received if it wasn't acknowledged, so it's actually reasonable
to let errhandle() request we send as many as it likes. 

If you're interested in this kind of programming, btw, I recommend
Steven's Unix Network Programming.  

--jkl