[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