FreeTDS Development Group

["Scott C. Gray" <gray AT voicenet.com>]

As mentioned before, I have been in the process of imlementing cancels
in the TDS layer.  As part of this effort I had to re-implement most
of the network calls (I actually implemented a little network layer).
Everything is working dandy except that I a trying to roll the
timeout changes back in that were made by Jeff (the comments don't say
Jeff's last name or e-mail address). 

While I am doing it I discovered something that concerns me.

It looks like the way the timeouts work is that if tds->timeout
is set, then any call to read or write to the network (all calls
to tds_read_packet() or tds_write_packet()) will return if 
tds->timeout seconds has expired without reading an entire packet.

The problem is that if the timeout period is reached while in
the middle of reading a packet--which is unlikely but possible,
the packet stream is then effectively corrupted.  The next call
to tds_net_read() will read the first 8 bytes off the network
thinking that it is a packet header when it is really the
last half of the last packet.

So, in either case, timeouts are likely to break things.

Also, if the timeout period is reached and no bytes have been
read yet, all calls to tds_get_<datatype> will return 0, which
will screw up the parsing of the TDS stream.

So, my question: what are timeouts _supposed_ to do? I suspect
that they are intended to cancel the current operation, but I 
am not sure.

-scott

--
Scott C. Gray <gray AT voicenet.com>     "my keybard is brken"
       http://www.voicenet.com/~gray/sqsh.html