Skip to Content.
Sympa Menu

freetds - Re: [freetds] dbsqlexec() never returns

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Perception Technologies Ltd <ptl AT perceptions.co.nz>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] dbsqlexec() never returns
  • Date: Fri, 01 Jun 2007 09:19:24 +1200

Thank you for the rapid response.

James K. Lowden wrote :
> Thank you for the patch. I haven't been able to look at it closely, but
> on first review it looks like you may have defeated the 1-second timeout,
> which defeats the dbsetinterrupt() support.

and Frediano wrote:
> yes, but doing so dbinterrupt cannot work

Yes, I realise that I was disabling the 1 second interrupt, but I was not using that code (which was new to this release) so I removed it. Because I was not 100% clear on the purpose of the code, I did not feel that I would be able to come up with the best solution. I wasn't submitting my changes as a patch, merely informing you of my changes, which happened to fix an intermittent hang that we were experiencing.

James K. Lowden wrote :
> Expect to see it addressed before our next release. If you would, it would
> be a great service to install the snapshot after I "fix" it, to see if my
> interpretation of your patch actually corrects the problem you first found.

We will move to the next stable release once it is released. But there will be a delay before it goes into production, but once it does I will let you know.

Frediano wrote:
>... please consider a new snapshot (tomorrow one).
> I'd be glad if you could test this

Unfortunately, we never see the problem on the development, nor on the test system, and I am unlikely to be allowed to risk disruption to the live system to test this. But I'll see what I can do.

Frediano wrote:
> no, the idea is, on TDS_INT_TIMEOUT send cancel and wait reply from server.
> On next timeout library should say, "ok, we waited quite a lot after cancel,
> now stop and close". We can't return safely without losing syncronization.

Thank you for the explanation. I will get the new snapshot, and use this as an argument to try and get it installed.

Frediano wrote:
> Mmm... here nput <= 0 should be mathematically impossible...

Ah yes. A later revision has added an nput <= 0 earlier, so this code is now superfluous.

Thanks for all your work on such a great product.

Cheers,
Brent.





Archive powered by MHonArc 2.6.24.

Top of Page