[freetds] new network timeout code

James K. Lowden jklowden at freetds.org
Mon Jan 8 21:46:31 EST 2007


ZIGLIO, Frediano, VF-IT wrote:
> > Do you think it's possible for tds_select to call 
> > tds_send_cancel?  If so,
> > tds_select need return only >1 (OK) or <1 (FAIL).  
> > 
> 
> Mmmm... I think you should check what happen if tds_send_cancel is
> called inside tds_goodwrite writing another packet... I think that in
> this situation we could send garbage...

Quite right.  We have to percolate the timeout error up the stack to a
place where the cancel packet can be sent.  

> I was thinking also about async cancellation. Perhaps if we are sending
> some information instead of sending another package we should just set a
> variable like in_cancel that tell "we need to send a cancel". This cause
> if a signal is called while we are sending a packet we should support
> calling tds_send_cancel inside the signal (this is required by
> ctlib/dblib).

That's a good idea.  

It reminds of programming a modem driver for XON/XOFF back when 1200 bps
modems were new.  One day it dawned on us that *receiving* XOFF meant we
had to stop *sending* immediately but we had to *continue* *receiving*. 
The code we were working with didn't do that; it stopped reading right
away, so of course it never got the XON.  No one had noticed with 300 bps
modems because at that speed we never got XOFFs.  

Ah, yes.  6 MHz, 640 KB, memory-mapped video, and a 20 MB "fixed" disk. 
Who could want more?  

It was a couple of years later that someone at Hayes assured me on
Compuserve that 2400 bps was about the limit of what was technically
possible on a voice line.  

Regards, 

--jkl


More information about the FreeTDS mailing list