Skip to Content.
Sympa Menu

freetds - RE: [freetds] tdsdump SIGSEGV with mt apps

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] tdsdump SIGSEGV with mt apps
  • Date: Wed, 18 May 2005 18:25:23 +0200

>
> > Once a query is sent to the server, the line is absolutely
> quiet until the
> > server answers (if ever). There is no interim message or
> heartbeat of any
> > kind.
> >
> > I don't understand why the stack would close the connection
> merely because
> > it's idle. A telnet session can stay up indefinitely without anyone
> > typing anything.
>
> Well, there have to be TCP keep-alives but this will happen
> transparent
> to the application, etc.
>
> Let's assume for now that based on this information about how
> the protocol
> works, a seperate network timeout is not required.
>
> In this case, select needs to be populated with query_timeout. Do you
> want me to update the patch or do you want to do that Frediano?
>

Attached a patch from current snapshot for net.c. The patch have a small
story, I discard our code, merge your (I was not able to patch) then
edited a lot looking at our old code and fixing tests. I'm still not
fully satisfied, I don't know how dblib interrupt code behave... The
main idea before our rewrite (some months ago) is to have a single
timeout (query_timeout), if upper layer (like dblib) require polling
simply set tds->query_timeout to polling and check real query timeout in
tds->query_timeout_func. I don't think current dblib implementation
follow this advice. Also libTDS should pass the complete timeout calling
query_timeout_func. What do you think about?

About thread safety in dblib. I committed another patch (yesterday, so
you can find it in snapshot) for context, it use a sort of reference
counting (one for context and another for init), thread test works well
(valgrind reported some problem with glibc but we can't patch the world
:) ). It seems also that current code do not require recursive mutex.

freddy77

Attachment: post64.diff.gz
Description: post64.diff.gz




Archive powered by MHonArc 2.6.24.

Top of Page