Skip to Content.
Sympa Menu

freetds - Re: [freetds] new network timeout code

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] new network timeout code
  • Date: Mon, 8 Jan 2007 21:46:31 -0500

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




Archive powered by MHonArc 2.6.24.

Top of Page