FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> > 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