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, 13 Apr 2005 17:01:03 +0200

>
> On Wed, Apr 13, 2005 at 12:52:46PM +0200, ZIGLIO, Frediano,
> VF-IT wrote:
>
> > I'm thinking about applying or not your patch. Your patch solve the
> > problem however is it the right way to fix it??
>
> Almost certainly not, it's at best a work-around for the problem, not
> a fix.
>
> The problem is that FreeTDS is riddled with these global
> structures all
> over the place and I'm not game to try and re-write the whole
> lot just
> for this.
>

Well.. dblib is not designed to be thread safe and honestly I don't want
to complicate logging that much. If I have a function like

int tds_get_size(int token) {
...
}

and I want to do logging I just call a function like tdsdump_log without
many problems. If I want to make tdsdump_log dependent on TDSSOCKET I
would have to add a TDSSOCKET* param to every function in libTDS... it
looks bad and it slow down only for logging activity... For this reason
we use global variable. Remember that all libraries (dblib, ctlib and
odbc) are not fully written to be thread safe. Mainly you must serialize
every function that use a connection (DBPROCESS in dblib, HDBC in ODBC
and I don't know which structure on ctlib). The only exception is cancel
(that can be called in thread/signal). However like you I would like to
avoid problems if a library is used in different thread each with its
connections (for example in a multithreaded Apache).

> > If I remember you posted a patch to fix some problem with dblib and
> > multi-thread. I think is the right time to review it.
>
> Yes, please! At the moment, I'm experiencing problems with FreeTDS
> and network timeouts which means I have to either fix these or
> perhaps move to a newer version of FreeTDS.
>

I'm sorry to say that 0.63 still do not handle correctly cancellation
(at list using multithreading/signal) and that 0.64 is not fully
complete as you can see from this line (token.c, tds_process_cancel)

/* TODO udate this shit, use
tds_process_results_tokens/tds_process_row_tokens */

I'm working on this stuff (I must say that I started some hours before
your post... strange coincidence...)

> I had a look at the latest snapshot and it appears that much of
> the code around network I/O has changed. Has it been fixed? I was
> looking at goodread() and it still has bugs. What state is it in?
>
> I've made a number of changes to goodread() for it to
> properly support
> timeouts but it does not pass all of my test cases.
>
> It may be worth re-writing it from scratch. The function is
> filled with
> incorrect behaviour such as neglecting to call FD_ISSET() before
> recv() after the select().
>

I know, what's the problem in that?? If select return > 0 it set a flag.
There is only a flag so if retcode > 0 it must be FD_ISSET() true...
also note that socket is now always not blocking so recv would return
EAGAIN.

> So I'm now left to ponder where I should put my effort. Port my dblib
> thread code to 0.64.dev.20050411 or fix the timeout issues in
> 0.63.dev.20040824 or both?
>

Please work on 0.64. Many thing has changed in cancel/timeout stuff. Is
more easier to improve thread safety in 0.64.

> Is anyone here confident that 0.64 actually has reliable network I/O?
>
> Thanks.

As said above better but still not perfect. Without timeout it works
perfectly but with timeout I don't know how hard we can go... If you
want an hint the key for thread safety reside in tds_set_state, make it
atomic and libTDS will be quite fully thread safe.

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page