FreeTDS Development Group

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

> 
> On Fri, Apr 15, 2005 at 05:49:44PM +0200, Frediano Ziglio wrote:
> 
> > I think so, it can be a performance bottleneck but how care for
> > performance while logging debugging information??
> 
> Agreed.
>  

So, have you a patch ??

> > I would use mutex for connection list/recftos members.
> 
> Okay, so the strategy moving is to protect the current global 
> structure
> with mutexes rather than moving TDSCONTEXT into a per DBPROCESS 
> structure. Agreed?
> 
> This is incremental change is least likely to introduce new problems
> when compared with something more significant as making TDSCONTEXT
> per-connection.
> 

Honesty I don't know how to handle TDSCONTEXT. TDSCONTEXT contains these
members

        TDSLOCALE *locale;
        void *parent;
        /* handler */
        int (*msg_handler) (const TDSCONTEXT *, TDSSOCKET *, TDSMESSAGE
*);
        int (*err_handler) (const TDSCONTEXT *, TDSSOCKET *, TDSMESSAGE
*);

In dblib parent, msg_handler and err_handler are always constant (like
TDSCONTEXT pointer). The problem is locale. Currently locale is never
changed (I don't know if a function which change global locale
informations exists.... currently not). libTDS (as you can see from CVS)
do not change these informations... How this structure behave in ctlib?
In ODBC is bound to environment and is constant (so I don't see still
any problems).
 
> > I agree, but easy mutex coding can be a very performance 
> bottleneck...
> 
> That's true, but at the moment, any serious use of dblib without
> mutual exclusion results in SIGSEGV and/or undesirable consequences.
> 
> I am sure most users will take poor performance over non-deterministic
> behaviour and corrupted data.
> 
> The implementation is such that it will not affect the performance of 
> non-thread based applications.
>  
> > By definition of its implementation... what does it mean??
> 
> It means if libtds itself is not thread-safe.
> 

Simply cause upper libraries are not fully thread-safe. We cannot change
this however I see some thread-safe problems (but I'm more optimistic
than you :) ). In all libraries you cannot read data from the same
connection from two separate thread. This help a lot our thread support
however cancellation must full thread safe and in ODBC I'm not sure that
you cannot use two separate statement from the same connection in two
threads...

freddy77